Project
A Webmarketer project generally matches one website and its subdomains.
Data scope
The data collected within a project is siloed and cannot be combined across several Webmarketer projects.
Keeping that siloing in mind matters especially for Webmarketer to correctly recognize a single user who browses from several devices or browsers.
Recognizing a single user can rely on several pieces of matching evidence:
- Identifying the user through their Webmarketer user cookie
- Reconciliation based on the data reported while browsing (user ID)
- Reconciliation based on event data (email, phone number, loyalty account ID, and so on)
That reconciliation is only possible within the scope of your Webmarketer project: you cannot use the matching evidence of other Webmarketer projects (yours or other people's) to improve reconciliation.
Webmarketer is an attribution tool whose purpose is to attribute events (their count, value or state) to the various traffic sources your visitors come to your websites through.
To do so, it needs the most accurate possible view of every interaction between your users and your brand. It is therefore better to group into a single project all of your web properties your users may land on (website, shop, documentation, customer portal).
Cross-domain tracking
Where the restrictions come from
The restrictions browsers put in place regarding third-party cookies aim to protect users' privacy by preventing major players (Google, Facebook, Microsoft) from collecting a user's browsing data from websites those players do not own.
That collection can happen through the addition of web analytics tools (Google Analytics), ad platform tracking pixels, or added features (YouTube player, Facebook sharing, and so on).
To limit what gets sent, browsers put restrictions in place and no longer tell third-party services (Google Analytics, YouTube, Facebook) who the user is when information is sent. That is the blocking of third-party cookies.
Sensible as that blocking is to prevent profiling, it is less so when you are trying to analyze your own first-party data without any ambition of selling it to third parties (directly, or indirectly by selling targeted advertising built on that data).
Google Chrome has already announced the end of support for third-party cookies. That major change was first meant to happen in 2022 but was pushed back to 2023.
In France, that browser accounts for nearly 60% of the market. As a result, identifying your users without grouping them under a subdomain is likely to be impossible, or severely degraded.
Alternative: using subdomains (recommended)
The most future-proof way to identify your users across all of your websites is to group your web properties under the same root domain.
That lets you set your cookies on the root domain, and therefore analyze a user's customer journey across all of your websites without losing the data of visits made to your websites on different domains.
For example, say you have 3 websites:
acme.com— showcase websiteacme-shop.com— e-commerce websiteacme-documentation.com— documentation and support website
Using three different root domains makes it impossible to identify a user through their user cookie. In that example, if an anonymous visitor (who has not left any information in a form, say) browses all 3 websites, they count as three different users.
By grouping your three websites into this structure:
acme.com— showcase websiteshop.acme.com— e-commerce websitedocumentation.acme.com— documentation and support website
the anonymous visitor now carries one single identifier across all of your websites, which makes it possible to analyze their customer journey taking all of their interactions across the 3 websites into account.
Alternative: federated authentication
When grouping under the same root domain is not possible, authentication is an acceptable alternative. That method works if all of your websites offer features reserved for signed-in users, or if your websites require signing in to view their content.
Among the three deterministic reconciliation methods, authenticating your users enables reconciliation based on the data reported while browsing. By sending the user's first-party identifier, you let Webmarketer group the visitor's sessions and rebuild their browsing across your various domains.
That solution will however not reconcile a visitor who comes to your website without signing into their customer or personal account, and their interactions on the other websites cannot be reconciled.
Alternative: link decoration
You can also decorate the links (by adding a URL parameter) between your various websites to carry the visitor's unique identifier. When they land on the destination website, the identifier is then loaded and used to track users.
That solution is very limited, though, because when the visitor reaches another of your websites through sources other than links from one of your websites (organic search, direct, social networks, for example) no decoration parameter is passed, and the user then counts as a new user.
That solution is very partial, and we do not recommend using it in production. If it is your only option, we recommend tackling the grouping of your websites under a subdomain first.
ITP
ITP, for "Intelligent Tracking Prevention", is a privacy protection feature built by Apple. It ships on all of its devices running Safari.
That system targets the lifetime of cookies, whose persistence is essential to recognizing a visitor across their various sessions over time.
Safari, across its mobile and desktop versions, holds nearly 21% of the browser market. We recommend taking the following section into account to make your data as faithful as possible.
ITP's first historical action was to limit the lifetime of third-party cookies. Third-party cookies can be justified by two technical constraints:
- The system you embed in your website is hosted by a third party that wants to identify visitors That is the case with Facebook (like buttons) and Google (YouTube player, or Google Analytics), for instance
- You use a third-party software solution to make building first-party data easier That is the case with Webmarketer, for instance: you use a tool that does not exploit your data for its own benefit, but gives you access to it.
In that second case, since the collected data belongs to you and is not used for advertising purposes by Webmarketer, you can (and legitimately should) place the Webmarketer tracking script on a subdomain of your root domain through a CNAME record.
Data is then collected on your own domain, and the cookie lifetime restriction therefore does not apply.