Tracking Cookie Armageddon

[Graybeard]

Tip: the newest version PHP 7.3.0 will accommodate the attribute "SameSite"
Setting SameSite in Nginx currently works (but is a more static and structured value)

 add_header Set-Cookie "cip=$remote_addr;Domain=.hoodfo.com;Path=/;HttpOnly; SameSite=strict; Max-Age=100000";

>>>This new IETF specification describes a new attribute that can be set inside HTTP headers. Called "SameSite," the attribute must be set by the website owner and should describe the situations in which a site's cookies can be loaded.

A SameSite attribute of "strict" will mean the cookie can only be loaded on the "same site." Setting attributes such as "lax" or "none" will allow the cookies to be loaded on other sites as well.

All old cookies that don't have a SameSite header will automatically use a "none" attribute, and Chrome will consider them as cross-site --or tracking-- cookies.<<<
Google Chrome to support same-site cookies, get anti-fingerprinting protection | ZDNet

What does this mean?

On a first referral the tracking can work with your affiliate code in the URL.
Return referral revenues that are allocated by the 30 day (or more) persistent cookie may be history

Certain advertising tracking that is done by cross domain cookie tracking is probably dead.

Are cross-domain image tracking (image pixel) dead next? IDK ...

 

[Graybeard]

I just spent too much time setting it up
on Ubuntu 18.04
these are my notes maybe you can reference them

install-php7.3

CAVEATS:
1. If you are using php-gearman, you need to add ppa:ondrej/pkg-gearman
2. If you are using apache2, you are advised to add ppa:ondrej/apache2
3. If you are using nginx, you are advise to add ppa:ondrej/nginx-mainline
   or ppa:ondrej/nginx



sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo add-apt-repository ppa:ondrej/nginx-mainline
sudo apt-get update

sudo apt-get install php7.3

then
php7.3-fpm
install what's missing (grrr)

sudo apt-get install php7.3-fpm php7.3-cli php7.3-mysql php7.3-gd php7.3-imagick php7.3-recode php7.3-tidy php7.3-xmlrpc php7.3-common php7.3-curl php7.3-mbstring php7.3-xml php7.3-bcmath php7.3-bz2 php7.3-intl php7.3-json php7.3-readline php7.3-zip

change the nginx conf to:
fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
from 7.2 then:
# sudo nginx -t
#^^I like to test first & fix any errors
# sudo service nginx reload

__DONE__ (till the next update )

 

[Graybeard]

Back to the real issue:
Chrome may start disallowing (ignoring) tracking cookies without their security policies set.

As an affiliate this can cost you a lot of money if you think that your 30 day or longer tracking cookie will work
in the case that a referral of yours returns and decides to buy.

inapp tracking and wi-fi /IP location for intent remarketing will not be affected buy this (keep that in mind).

 

[Graybeard]

According to an article by the Wall Street Journal, publishers’ revenue could drop by 50% in 2020

Simpler reasoning perhaps ...

 

[Phill AdsBridge]

You have done a lot of work! Great!

 

[Graybeard]

Facebook is a laggard

I am ahead of the curve

 

[MaxiChucks]

Hey all. As an affiliate vendor what samesite settings exactly are optimal so the duration and tracking work optimally across different browsers for my affiliates? I don't know how to setup cookieless tracking atm so have to rely on first-party cookies for some time.

 

[Graybeard]

1. Registering a user and having him login (probabably not applicable to your business)
2. Backend logging (resource intensive) ip2long (PHP), Maxmind Geo-city location (city,state,country [not that accurate] the user's current server (ISP) location)
3. A URL ?session_ID=23jdfl49sl023jJe3 with that ID related to referral details session only (no return capture)

^the above is for affiliate tracking and accreditation (commissions)

 

[MaxiChucks]

Thanks, do I understand correctly that affiliate cookies set to samesite 'none' will only track in Chrome, not the other browsers?

 

[Graybeard]

>>>This new IETF specification describes a new attribute that can be set inside HTTP headers. Called "SameSite," the attribute must be set by the website owner and should describe the situations in which a site's cookies can be loaded.

A SameSite attribute of "strict" will mean the cookie can only be loaded on the "same site." Setting attributes such as "lax" or "none" will allow the cookies to be loaded on other sites as well.

Test all browsers and the user can set how he will allow tracking now.
Cookies are no longer FORCED on browsers.

The dilemma is that you can refuse service when the cookie is not set --but you also lose the potential conversion of the user.
Mobile browsers are harder to reset from their factory setting and the users are generally unsophisticated --can you convert mobile well now --some can.
For desktop users, for reason of the cookie slippage, you should raise the %payout to be fair and retain affiliates.
You need to know your real numbers. I could only make a guess. Even my ad traffic that I check for cookies will vary a lot by source and quality --so any percentage of loss I might give would be subjective to my situation and traffic source quality.

 

[MaxiChucks]

Test all browsers and the user can set how he will allow tracking now.
Cookies are no longer FORCED on browsers.

The dilemma is that you can refuse service when the cookie is not set --but you also lose the potential conversion of the user.
Mobile browsers are harder to reset from their factory setting and the users are generally unsophisticated --can you convert mobile well now --some can.
For desktop users, for reason of the cookie slippage, you should raise the %payout to be fair and retain affiliates.
You need to know your real numbers. I could only make a guess. Even my ad traffic that I check for cookies will vary a lot by source and quality --so any percentage of loss I might give would be subjective to my situation and traffic source quality.

Thanks for the info. Do you mind if we work out a step by step instruction for affiliates to check if a site has properly functioning tracking cookies? It's probably better for the whole business to keep things up to date with tech changes. If affiliates know how to spot issues and complain the market has to shape up and adapt to changes.

I was exploring some big sites to see how they have done it. Please help out with corrections and adds to this process if I am explaining things wrong. You obviously know more than me so maybe I am just wasting words explaining this

Let's use Firefox as an example since it already uses the new stricter cookie rules by default with the latest version:
1) Click an affiliate link that takes you to the site you want to check (let's say chaturbate.com in this example)
2) Right click on the page and chose 'inspect element'
3) Check storage section - cookies
4) Look for cookies with aff/affiliate keywords in their names, check values. This will show cookie expiry dates and samesite values. Chaturbate has 'none' set for samesite (so can we assume they have not updated their cookies properly?).
Chaturbate:
affkey
fromaffiliate

5) Check javascripts/js under 'debugger' section. Look for javascripts that have affiliate code inside.
Chaturbate:
Can't find anything relevant to cookies in javascript, just a bunch of ads and analytics js.

Greybeard, what's your take on this?

 

[Graybeard]

That will work when the referrer data is not encrypted in the cookie --that's the last cookie shaving trick I have seen to defeat this.
Sometimes, if you do have a cookie proven present in your browser; try Making a test purchase by just opening the cart form and then reading the page source code --there should be a reference to the data in that cookie in the POST data (sometimes).
However, there could be a reference made by the session id in the POST data also.

OK, let's say this is not an intentional shaving issue --but a browser security or other bug in transferring the right cookie data ... This can happen when the payment domain is not an exact match as the domain setting the affiliate cookie.
Check in Google Chrome too ... Different browser have different default policies; F12 then ---

1. Setting your own website cookie, and;
2. then fetching it with a script,
   
3. then doing something is how I have always checked the user's browser for 'cookie policy'.

The reasoning in all is in vain if that user's browser is not comparable with the cookies.

This is one element of affiliate slippage in cookie driven websites. Unintentional perhaps --but there is a beneficiary of this occurrence.