Introduction
As digital e-commerce marketers, we have enjoyed many years of relatively effortless visitor tracking through client-side tracking pixels. These favorable visitor tracking capabilities have allowed us to perform efficient marketing activities with exact targeting. Also, this precise visitor tracking ability has given us solid, actionable intelligence from our website analytics tools.
However, over the last couple of years, marketers have seen their visitor tracking capabilities gradually degrade. The problem has now become so large that it’s causing major concern for all digital marketers worldwide.
The cause, of course, is the rise in attention to user privacy on the Internet. ITP, ETP, adblockers, ATT, CCPA, GDPR, ePD etc. The list of regulatory policies and browser restrictions keeps growing and is slowly but surely shutting down the possibility of tracking visitors in conventional ways.
Change isn’t coming; it is already here. This is your wake-up call if you want to sustain your personalization, retargeting, and analytics abilities. Below is a timeline of (some of) the critical privacy milestones that we’ve seen over the past few years. And several more initiatives are upcoming.
Through ITP, Apple’s Safari browser has effectively cut 1st party tracking cookie lifetime to 24 hours. I.e., any visitor action taken after 24 hours will not be tracked by pixel technology (or server-side API integrations). According to our data, 30-60% of users are using Safari (depending on website audience).
Likely, the crack-down on client-side pixel tracking will continue over the following years, with many initiatives already underway by large players, effectively making that tracking technology even less reliable. Marketers continuing to rely on pixel tracking are sure to meet increasingly worse campaign performance and worsened analytics intelligence.
How does this affect my online business?
Your digital marketing efforts are already severely negatively affected. Your website analytics and campaign attribution models are missing data, and your retargeting campaigns already have far lower performance than just a year ago. In short, for online businesses, especially e-commerce, the effect of ITP is both severe and acute.
So, in all this darkness, is there no hope for personalization and retargeting?
My own personal belief is that personalization and remarketing will remain the best marketing strategies for the foreseeable future. However, their lifeblood is and will always be the tracking of visitors.
What is important to understand is that all the recent changes in how browsers deal with 1st party cookies, have broken the “default” visitor tracking solutions, provided to website owners, by their ad-network and analytics services providers. In other words; the time when e-commerce marketers could simply rely on installing pixel-scripts on their websites for solid visitor tracking has come and gone. Marketers and site owners now need to take actions beyond these default setups if they want to continue with profitable marketing strategies that rely on visitors tracking, such as remarketing and personalization.
If you are a site owner or e-commerce marketer, I invite you to read on.
How does visitor tracking work and how is it affected by ITP?
Two essential things are needed for remarketing and personalization to work:
- Event tracking.
- Visitor identification.
An “event”, in this context, can be described as information about an action that a visitor takes on a website. These events are sent to the ad-network whenever a visitor generates an action, like visiting a specific page, adding a product to the cart, or completing a purchase. However, event tracking information is only useful when successfully paired with a user identification string. Here’s an example of what information could be included in an “AddToCart” event sent back to an ad-network:
- event = AddToCart
- content_id = 123456
- content_type = product
- value = 299
- currency = USD
- product_category = Headphones
- brand_name = Sony
- user_id = abc123
The value of the user_id attribute (“abc123”), is usually a cookie that has been placed in the user’s browser at a previous point (by the ad-network). The ad-network receiving this event information can resolve this unintelligible string to a user-ID in their database (anonymized or not). This is how ad-networks can offer their advertisers services such as retargeting and personalization. Because they know that user X viewed product Y, a marketer can remarket product Y to user X at a later point.
Now, if the ad-network’s user_id cookie has been deleted from the user’s browser, the event will still be sent to the ad network, but without the valuable cookie identifying the user (or with a “fresh” user_id cookie value which is equally useless). In those cases, the ad-network is unable to match the event to a user in their DB. The result of course being that the ad-network cannot offer personalization or retargeting services to its advertisers.
In other words; the persistence of cookies is important for retargeting and personalization to work. And this is where Apple ITP has put the dagger in the backs of e-commerce marketers.
ITP is an algorithm that runs in-browser (client-side) directly in the user’s Safari browser. The most important ways that ITP blocks visitor tracking are:
- By blocking all 3rd party cookies.
- By limiting the lifespan of script-set 1st party cookies to 24 hours whenever ITP identifies a cookie having cross-domain tracking capabilities.
- By limiting the lifespan of all script-set 1st party cookies to 7 days.
Ad-networks have tried to counteract ITP in various ways, but Apple has been swift to roll out incremental updates of their ITP policy and shut down the various loopholes exploited by ad-networks.
Interestingly, Apple’s ITP doesn’t treat all 1st party cookies the same, and this is where it gets a bit technical. Consider the following infographic:
Apple’s ITP recognizes that all 1st party cookies are not necessarily “evil” tracking cookies. Apple ITP’s strategy is to filter out the “tracking cookies” from the “useful cookies” and penalize the “tracking cookies” with a shorter lifespan.
One can assume that the reason why Apple can’t simply ban all 1st party cookies, as they did with 3rd party cookies, is because that would break essential functionality on most websites. Limiting functional cookies and server-side set cookies may for instance break essential things like user login sessions, user preferences, user cookie consent, etc.
Critical insight:
- If tracking cookies are set by the server in a 1st party context, ITP will not restrict those cookies’ lifespans.
- If server-side APIs are implemented to report the events back to ad-networks, ad-blockers and other browser-side tracking prevention become irrelevant.
But will Apple Safari and other major browsers start restricting server-side set cookies next? I believe it is unlikely that server-side set cookies will be restricted anytime soon since they are an essential cornerstone of most websites’ functionality and therefore; any browser enforcing such restrictions would become less popular among users.
I believe that during the next few years, script-set cookies will be more and more restricted. But if you can leverage server-set cookies and implement server-side tracking APIs, you’ll be able to sustain personalized marketing and analytics performance for the foreseeable future.
What can I do to fix my visitor tracking?
First, we assume that your goals are aligned with the following:
- You want to respect your visitors’ choice of privacy settings and to follow all privacy laws and regulations.
2. You want to remain competitive by:
- Sustaining the sales coming from personalized remarketing campaigns.
- Having reliable marketing attribution and site analytics.
- Expanding your ability for measurement of off-site events like physical sales.
If you are aligned with the above and you are ready to retake the Initiative from Apple’s rather intrusive cookie restrictions as described above, we recommend a 3-step approach (in order of importance):
- Make sure your website application leverages server-set cookies to extend cookie lifetimes and avoid unwanted cookie deletion.
- Revisit how you ask for user cookie consent.
- Consider setting server-side event reporting to your most important ad-networks and analytics partners as a long-term strategy.
Step 1: Extend the lifetime of 1st party tracking cookies
As all major ad-networks and analytics solutions rely heavily on 1st party cookies with cross-domain tracking capabilities, and Apple Safari ITP now effectively has decreased these cookies’ lifetime to 24 hours, your main objective is to find a way to extend the lifetime of these cookies. If you can manage that, you are sure to see a major uplift in your marketing and analytics efforts.
In my view, the most efficient solution is to let your server manage all tracking cookies as server-set cookies. With server-set cookies, you give yourself the power to decide the lifetime your 1st party tracking cookies should have. Of course, remember to follow your local privacy laws and respect your visitors’ privacy choices for cookies.
If you have the technological know-how and time to achieve the above, I recommend going down that route. If not, you may want to consider using services such as re:cookies, which provide a plug-and-play solution for the extension of lifetimes for all your 1st party tracking cookies. Re:cookies might also be a good interim solution for your website, to allow you to reclaim the benefits of long lifetime cookies already today. At a later point, you can invest in the technical development required for adding server-side tracking solutions (which mainly solves the problem of ad-blockers that prevents pixel-scripts from reporting events to ad-networks).
Re:cookies provide you with a drop-in solution to the cookie problem described above. By leveraging long-lived server-side cookies, you immediately increase your advertising performance and improve your analytics intelligence. The solution plugs into your existing website and converts all short-lived client-side marketing cookies to server-side cookies. And it accomplishes this in a transparent way, so you don’t have to modify your existing marketing pixels, events, analytics, or website.
Step 2: Review how you ask for user consent
Take the time to review how you ask for your visitors’ cookie consent. We see that many cookie-consent dialogues have poor designs, causing unnecessary loss of user consent. To maximize the percentage of your visitors that approve your consent dialog, we recommend a dialog similar to this:
This type of dialogue will give you maximum cookie-consent from your users as most users don’t care and will quickly click the green button to make the dialogue go away.
The threshold should be slightly higher to reject cookies by having a “Cookie options” section that allows users to customize their cookie settings. This lets everyone easily reject cookies if they want to, but it helps steer most users into accepting them.
If you don’t get cookie consent, make sure you respect your visitor’s wishes and don’t store tracking cookies or send personally identifiable tracking events.
Step 3: Server-side APIs
We see is a lot of buzz around server-side APIs as the solution for publishers’ recent losses in tracking capabilities. However, in our view, server-side APIs are only a part of the solution as they mainly solve the problem of ad-blockers and poor connectivity. While those problems are useful to solve, the bigger issue here lies in the limitation of cookies’ lifetime (addressed in step 1 above). Because, if the cookies used to identify visitors are not available, server-side APIs don’t add much value to the equation.
In essence, server-side APIs have the same purpose as tracking pixels, I.e., to send visitor tracking data back to 3rd party servers (like Facebook, Google Ads, Google Analytics etc). But, instead of relying on JavaScript to send important data back to 3rd party ad-networks and analytics servers (from the client’s browser), the information is transmitted directly server-to-server, which makes the communication much more reliable. You also gain full control over what data is sent to your partners. Whereas tracking pixels may share data that you don’t necessarily want to be shared.
So, with these strong upsides, why wasn’t server-side APIs the preferred solution to visitor tracking from the beginning? The answer is simply that they are significantly more cumbersome to implement for publishers. The only reason they have won recent acceptance among publishers is that traditional pixel tracking setups have become significantly less efficient.
All major ad-networks and analytics services now offer server-side APIs for publisher partners and the general recommendation is to run them alongside the old pixel tracking solutions (with event deduplication) for maximum tracking capabilities.
The good news is that all server-side APIs are, by default, compatible with the use of server-side cookies. This means that by implementing server-side cookies, your server-side API implementation will have a much stronger positive impact as you’ll be able to identify users over much longer time frames.
Conclusion
Privacy on the Internet is important to all of us. The choice to be tracked or not should be up to each individual user, not ad-networks or any single company (hello Apple). It’s widely known that a healthy, open, and free Internet can exist in part thanks to private companys’ marketing budgets that support publishers in their endeavors. Anonymized visitor tracking with user consent for advertising purposes is not a bad practice that must be banned. Nobody likes ads, but relevant ads are better than irrelevant ads and as long as the choice lies with the user, we shall all be fine.