When posting a soundcloud track, I wish to reduce the length of the internet address, which leads to the track. Normally the track contains the uploader's username and also the track's title.
Unfortunately soundcloud's own URL shortener has been abolished.
A workaround could be, to extract the track ID number, because mostly it's shorter than the track title.
How can I build a plain internet address which contains the track ID number? I tried, but it does not work.
Does something like this work for you?
You can either shorten a link to a random URL or use the "Customize your short link" option to add the track ID if it is important.
Related
I have given an option to my users to share my website on whatsapp. And I want to know how many users land back on the website using the shared link. Hence, the shared button opens this link:
https://wa.me/919876543210?text=https://www.mywebsite.com?utm_source=whatsapp&utm_medium=share
But this URL considers the end &utm_medium=share as a part of the wa.me URL, and shares only https://www.mywebsite.com?utm_source=whatsapp on WhatsApp. So instead I did this:
https://wa.me/919876543210?text=https://www.mywebsite.com?utm_source=whatsapp%26utm_medium=share
which shares the correct URL on whatsapp: https://www.mywebsite.com?utm_source=whatsapp%26utm_medium=share, but when I open it, the UTM params are not captured by GA.
What is the way out of this loop?
There's a more elegant way of doing it than utm params. Have something like: https://wa.me/919876543210?text=https://www.mywebsite.com?t=wa
See how now it's shorter and more elegant to a user? Now you have two good options.
Make a conditional redirect on your site from any url that has a t=we query param to whatever utm param you want with no restriction.
And even more elegantly: use GTM to parse pageviews where there's a t query parameter set, then make a neat lookup table where the input would be the value of t and the output - whatever you want to name it. Then use that lookup table's value to set your session-level custom dimension in pageviews.
Why a custom dimension and not UTM? Because when using UTMs, you're affecting your attribution. And sessions. You can easily override organic or paid attribution with some meaningless whatsapp attribution. Well, yes, if you don't use attribution at all and you don't care about GA session breakpoints, then sure, UTMs are just easier.
Also, try escaping the &, but not much hope there.
Currently I'm using this link forwarding structure:
bit.ly/{some_hash} > example.com/s/{ID} > example.com/blog/full-seo-optimized-url/
Because the id of the blog never changes but the url might change (e.g. spelling mistake), I'm forwarding my bit.ly short urls to a special subpage (/s/{UD}) that will eventually get the full url from the database and forward the visitor to the blog entry.
Pros:
If the URL changes, the bit.ly short link will still work and forward to the updated url
(Possible) Cons:
Might be seen as spammy method (hiding target link)?
Might be violating any terms of service?
... ?
Therefore I would know, if this is a good and proper way or if I should remove the step in the middle?
Those redirects will cause a slower user experience and when used will cause a loss of PageRank being sent to the destination.
I'd avoid doing it where possible.
There are URL shorteners out there that let you directly edit the destination which would avoid your need for the middle redirect.
You also want to avoid changing the destinations URL as other people will not use your fancy redirects and you will lose PageRank every time they change.
Have gone through https://dev.twitter.com/docs/streaming-apis/parameters
Per documentation it should be able to track URLs such as example.com/foobarbaz but I can't seem it to be tracking such URLs. It just doesn't return me any result when I tweet this URL and track it using Streaming API. Am I missing something?
Pretty late, but I found this by Google so this might help someone...
There are a few answers to this. The main answer being that Twitter treats URLs differently than anything else.
First, make sure you do NOT include the "www".
Twitter currently canonicalizes the domain “www.example.com” to “example.com” before the match is performed, so omit the “www” from URL track terms.
For me, sending the track parameter as "example.com/foobarz" and then tweeting "a test, please ignore: http://example.com/foobarz" worked perfectly.
You can NOT, in general, ask for substrings of URLs:
URLs are considered words for the purposes of matches which means that the entire domain and path must be included in the track query for a Tweet containing an URL to match.
But if you are willing to take every tweet from the whole domain (and a bit more edge cases), Twitter will accommodate:
Finally, to address a common use case where you may want to track all mentions of a particular domain name (i.e., regardless of subdomain or path), you should use “example com” as the track parameter for “example.com” (notice the lack of period between “example” and “com” in the track parameter).
All quotes are from the Twitter docs: https://dev.twitter.com/streaming/overview/request-parameters#track
They have more information, including examples.
Good luck!
Twitter's published mechanism for linking to tweets is to use "http://twitter.com/{ScreenName}/statuses/{Id}" -- where ScreenName is the user's screen name and Id is the unique Id for the tweet. But Twitter also allows users to change their screen name, and would probably allow two different users to have the same screen name if they are sufficiently distanced in time.
Given this, what happens to the tweet URL? Can it not be considered permanent?
I have noticed something that may provide the answer. You can actually substitute any string at all for {ScreenName} and the url still works (it will redirect to a url with the correct screen name). So it would seem that the only bit that really matters is the {id} - which obviously will be permanent, and from that Twitter will work out what the screen name is and redirect to get the right looking url - even if the {ScreenName} has changed
I'm writing a URL shortener similar to tinyurl and I'm wondering how to keep track of URL's that are already shortened using my service? For example, tinyurl generates the same tiny URL for the same long URL regardless of who creates it. How can this be achieved that is scalable? Bitly also does this though they generate a new URL per person. However, they are able to track the aggregate (total # of) clicks for the long URL - How?
Thanks,
They store the URLs in their database, associated with the short URL(s). How else would it be done?