Need to setup a tracking script to work with our pixel tracker for our affiliate sites.
New here? Learn about Bountify and follow @bountify to get notified of new bounties! x

oday we have a pixel tracker we put in some of our partner sites so when the page gets hit we see a request which we log, this gives a rough idea of how much traffic the landing page is getting. We want to now have more than just a dumb pixel request we want to see how much traffic crosses between our main site and the partner sites. to do this we think we need the following

script is loaded on the partner site and our main site (different domains)
Set cookie for the user, ideally in the cookie we can keep domain/url and time data so we know the first time this user touched either our site or our partner sites.
then each time they hit a different domain site which is running our script we want to try and put a history together so we know if they hit just 1 property at some point in time or more. ideally in the cookie we can track something like this


etc... i dont imagine this will be more than a handful since its really just in our partner network of sites.

next we want to capture the "current url" they are on when the script runs. so in the cookies we have the persistent list of domains above but we want to capture current url so we can get a sense of what page they were on when they got our scrip. we will not keep a history of urls. just history of domains + current url

next, on each script run we will make a request to our pixel. we will need to send some of this cookie info serialized in the name of the gif, so the server can process it. I might need your help coming up with something smart here but i think it would look something like this;domain2:timedate;domain3:timedate;url:

one note, we are not trying to track users or identify them. we only want to be able to track how value works betwene the sites. if the partner site is the origin of value which then comes to the main site or if somehow we have users jumping from various partners and so on. mentioning this for two reason, 1, we should all feel good about what we build with regard to user privacy, 2 I dont want anything above to imply that we want to try and get some more features around user tracking or weird stuff like unclearable cookies (forever cookies etc..)

you can assume a couple things. the script on the main site and the partner site reference a single js script which will be external to all of them. We can assume something like this for the purpose of concepts - this will be the gif GET request we make which will always reply with a small gif / 200 response - this will be the host of your javascript which will be placed on all of the partner sites and the main site. We thought this needed to be unique to avoid any cross domain issues. This way all of these sites are loading the same js from the same domain. and cookies thus would be on

I know these take a bit of time, so here is how we can do this bounty.

Winner - $100 bounty

2nd place - $50

3rd place - $25

awarded to Wuddrum

Crowdsource coding tasks.

1 Solution

Winning solution

Hey Qdev, here's my solution:



You can use to display/delete cookie and relevant data.

To populate cookies you can load the sites below and check back with the test site above.,output


A site simply needs to include a script tag that points to the tracker.js file. e.g. <script src="//"></script>


The implementation relies on two files tracker.js and tracker.html, these should always be next to each other.

Tracker.js: Referenced by a site in a simple script tag. Inserts an invisible iframe element in the site that executes the tracking code. When the iframe is loaded, it passes current window href to the iframe.
Tracker.html: Executed inside an iframe that's created by tracker.js. The iframe is needed in order for the tracking script to access and store cookies on the tracker domain. The data is stored in the default cookies, so that it can be easily cleared by users.

The tracking script checks if the domain name is already added to the history cookie, if not, then it adds a new history entry with the domain and current datetime in UTC. Currently the cookie expire date is set to one year.

Afterwards the pixel gif is called with domain history from cookies and current url. Currently the tracking pixel url looks like this: //{}&i={}. Where data parameter contains an encoded pixel data JSON object and i parameter is simply current date ticks, to ensure that the tracking pixel is retrieved from your site, instead of user's cache. If you prefer for the data to be used as the pixel filename, then it can be easily changed.

The implementation is compatible with all modern browsers and IE9+. It was working fine even on an old iPhone 3Gs.

Data Structures

The cookie history is saved as an encoded JSON object. This is the object's structure:

    "": "Thu, 11 Apr 2019 15:25:41 GMT",
    "": "Thu, 11 Apr 2019 15:25:41 GMT"

As you can see, it's a simple key-value pair of domain and its datetime, when first loaded. The domain names are not guaranteed to be in order, so you'll need to sort them by dates on the backend to reveal the chronological user's browsing habits.

The pixel data is sent as an encoded JSON object. This is the object's structure:

    "originHref": "",
    "history": {
        "": "Thu, 11 Apr 2019 15:25:41 GMT",
        "": "Thu, 11 Apr 2019 15:25:41 GMT"

Which is simply history data object concatenated with current page url.


I think the more logical alternative to all this would be to handle the cookie creation/tracking on the backend.

A site would do a simple tracking pixel request and the backend could inspect the attached cookies (if any) and construct/update new ones that get returned to the client along with the 200 response. The domain/page url could be retrieved from the Referer parameter that's sent by the client.

The big downside of this of course is that the tracking wouldn't be capable of fully working if the Referer header is not sent by a client (site meta property, removed by firewall, proxy etc.). But it might be better if it didn't work in these cases, since it honors the privacy level chosen by site or user.

Edit: Added compatibility information.

Thanks for the solution, I will need a little time to test this out. depending on changes to our pixel system I might need to ask for the params to be put in the gif name since our current system works like that. but let me come back to you on this shortly.
Qdev 5 months ago
Sure thing.
Wuddrum 5 months ago