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?
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!
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How do short URLs services work?
Hi,
Can anybody explain how short URL's (technically) work, and for how long are they valid? Any articles about how does it work are welcome too (but please no example provider sites).
Thank you in advance.
The short URL server has a database matching the short URL (or, rather the coded part of the URL) to the actual URL it represents.
When it gets a request, it looks up the coded part and sends a redirect to the actual URL.
So, for example, the URL http://tinyurl.com/so-hints
Will go to the tinyurl server
The server will lookup what full URL matches so-hints
The server will issue a redirect to the browser to go to the full URL
Create a unique identifier for a given URL, store it in a database,
when user visits short url, lookup the original URL in the database,
return a HTTP 3xx (redirect) status code to the client with the actual address.
Short URLs usually use a combination of numbers and lowercase and uppercase letters. A combination of exactly six elements of this set (26 + 10 items) for the path component can already provide 2,176,782,336 unique ids.
If you want to study some source code, this article highlights 7 open source scripts:
7 Open Source And Free URL Shortener Scripts To Create Your Own
There's just a relational database with a table that maps from a short, high-entropy string to a given URL. The short strings are created each time someone asks for one. They're not any form of encryption, it's just lookup.
In its simplest form it is just a key that is matched to a URL. From there you can add functionality.
Have a look at the spec for the Google shortener as they have a pretty balanced feature set: http://code.google.com/apis/urlshortener/v1/getting_started.html
They manage a list of short to long URLs and redirect each request to short URL to its original one
How do URL shorting sites like bit.ly or goo.gl work? Does anyone know what technique or algorithm they use?
Save the URL and generate unique key for the URL and store it in the DB. Use this key to navigate to the URL.
Do you need complex algorithm for this? :-)
If you want to make it complex.
Check for malicious URLs and block them
Have stats based on number of clicks
Have registrations and users have their own small urls
Develop plugins for browsers to generate short urls
etc etc