Implementing Adobe Analytics in a First-Party context
One of the things I love most about Adobe Analytics is how flexible it is. That is not only true for its interface, Analysis Workspace, and the numerous integrations, but also for everything that happens on the actual website where it is implemented. Almost every functional detail can be configured and tweaked, including the destination where the data is actually sent to.
For years Adobe has offered Analytics customers the Managed Certificate program, where Adobe would allow us to send data to a server that looks like it belongs to our own company (or, more specifically, our company’s domain). But upon closer inspection, those requests are only disguised as first-party and are actually still sent to Adobe’s servers directly instead of our own. And in addition to that, Adobe Launch and the Experience Cloud ID Service will still load their data from different domains that don’t belong to your company (adobedtm.com and demdex.net).
None of that is an issue for most customers. Or at least it hasn’t been: If you haven’t been living under a rock, you will have heard of all the initiatives companies like Apple with ITP or Google with FLoCs have started in the name of “user privacy” (which, in reality, just aim to ensure their positions as market leaders, but that’s a story for another day) and target things like user tracking, third-party cookies, and others. They are riding the waves that the impact of GDPR made a few years back and make lives hard for analysts and marketeers.
So, privacy is good, right? Why should we put in the effort to work around those new, technical limitations? Quite simple: The premise of this post is that you and your company respect your user’s choice and implement consent management. So if your users opt-in to being tracked (because they want to have the best user experience), shouldn’t you try your best to make that happen? Even if Apple or Google try to strong-arm us by creating technical hurdles, we should respect our user’s preferences even if Apple und Google think they know it better. On top of that, you could even read parts of GDPR as an obligation to do this, because you are obliged to keep user’s data correct and consistent, which is impossible if cookies expire immediately.
Another reason why you might need to bring your implementation to a first-party context might be strict legal regulations that your company has to follow. I know of quite a few people who work for banks or insurances (especially in Europe) who have to follow some seemingly absurd levels of data protection, where basically no third-party requests can happen on their websites. So, what can we do for Adobe Analytics to bring everything to our own domain?
The bright future: Adobe’s Web SDK
Before we start this post based on the current state-of-the-art (using AppMeasurement and the ECID service) I want to quickly appreciate the work Adobe has done to make the whole situation easier for us. With the new Web SDK (also called Alloy if you’re cool enough) things get much easier for us, at least if we operate it how Adobe recommends.
The first aspect of this is the way Web SDK handles requests to the Adobe servers. It bundles all the different requests, like for Analytics, Target, or Audience Manager, into one single request instead of multiple ones. This makes things already so much easier, compared to the multitude of requests to different domains that are happening on websites today.
While that is a nice advantage, the second aspect might be even more important in our context: With Web SDK, companies are encouraged to all follow the Managed Certificate route, where the destination of the requests is disguised as our company’s own domain. While that will only help in parts (due to how Apple’s ITP works, since it uncloaks those disguised requests) it definitely is a step in the right direction.
But for this post, we will stick with what most Adobe Analytics customers use today: Adobe Launch as tag manager, the Experience Cloud ID Service, and Adobe Analytics itself. If we want to bring all of those into our own domain, we have to put our own infrastructure into play. Let’s start with Launch.
Step 1: Self-Hosting Adobe Launch
Hosting Adobe Launch on our own server can be done in two different ways. The first one, which I will just briefly mention here, is what you would probably want to use in an actual production setup. In this scenario, you can give Launch the credentials and details for an SFTP server, which will then receive the library once it is built.
To create an SFTP destination, you first need to head over to the Hosts (1) in a property and add a new one (2):
On the then opening page, you can switch the Type to SFTP (1), which will give you a whole bunch of new fields to fill in:
Creating the actual connection is quite long and complicated (you can check out the documentation here) and way beyond the scope of this post. Just remember that it is an option and might be the best way to automatically deploy new versions of your library.
Another option, that is especially convenient during development, is to have Launch create a downloadable zip archive of the library and download it manually. To do that, we need to create a new environment. Go to the Environments (1) and create a new one (2):
On the following page, we need to give our new environment a name (1) and enable the Create archive toggle (2). That will reveal a new field, which holds the path of the Launch library on our server (3). Once all is in place, we can go ahead and save (4):
With that new environment created, we can open the install instructions (1) on the overview page to get the code snippet (2) for our website. Note that you need to replace the <your-host> part in the URL. To get the actual files, we need to download it (3):
Once we put the files on our server and include the code snippet, we can actually see how Launch is not loading over the internet anymore but from our own domain:
That’s the first step done already! This setup comes with some additional effort once you change anything in your library, since you always need to download and deploy your library again, but that should be fine for development.
Step 2: First-party Experience Cloud ID Service behind Proxy
The next thing we need to get under control is the Experience Cloud ID Service. With the ECID service, we generate the actual user id of our visitors, so it is quite important to get on our own domain. Right now, when a new user comes to our page, we can see the ECID service make quite a few calls, like the actual id generation (1) and id sync calls (2), to Adobe-controlled demdex.net domains (3):
For the first request in the screenshot, we need to set up a proxy on our own infrastructure. A proxy is a very simple web server that just forwards all requests to another server, which is exactly what we want. This is different from Adobe’s Managed Certificates program, since the request actually go through our own infrastructure, instead of Adobe’s disguised servers, before we then hand the requests over to Adobe. This whole handover is completely invisible for the client, which is why it is not caught by most tracking prevention systems. Most web servers (like Apache or Nginx) can act as a proxy, as well as most CDNs like Akamai. For our demonstration I’ll use the Apache server with a configuration like this:
SSLProxyEngine on
ProxyPass /id https://dpm.demdex.net/id retry=60
ProxyPassReverse /id https://dpm.demdex.net/id retry=60That’s already it! Those three lines instruct our server to forward all requests that go to /id on our domain to dpm.demdex.net, which is needed for the id creation.
Next, we need to instruct the Experience Cloud ID Service extension in Launch to use our own domain instead of demdex.net. Head over to the extension configuration in Launch and add three new configuration variables for audienceManagerServer, audienceManagerServerSecure, and idSyncDisable3rdPartySyncing as on the screenshot below. My local domain is mylocaldomain.local, which you need of course change to your actual domain:
The first two parameters instruct the ECID service extension to not send requests to demdex.net, but our very own domain instead. That would take care of call (1) in the screenshot before, but not of the other two id sync calls. To disable those, we set the third variable idSyncDisable3rdPartySyncing to false, which will get rid of them all together.
If you save and build (and download) those changes, you can see that now the id calls go to our own domain instead of demdex.net after Launch has loaded from our own server:
That will make your data protection team very happy to see! Now the only thing left is Analytics itself.
Step 3: First-party Adobe Analytics through reverse-proxy
To bring Adobe Analytics’ call to our own domain too, we need to extend our proxy configuration, in case of Apache, with two more lines of config:
ProxyPass /b/ http://yourcompany.sc.omtrdc.net/b/ retry=60
ProxyPassReverse /b/ http://yourcompany.sc.omtrdc.net/b/ retry=60This simple config allows us to forward each request that goes to /b on our domain (which is true for all Analytics calls) to the Adobe Analytics data collection servers. This is very different from how Adobe normally handles first-party implementations, since this call actually goes through our own servers and not only hides behind a domain name. Neat!
The only thing left to configure is the Adobe Analytics extension in Launch. On the config page, extend the General section and change the Tracking Server fields to your own domain:
One save, build, and deployment later we can refresh our page and see the Adobe Analytics calls now going to our first-party domain:
It works! Now Adobe Analytics calls are also going through our proxy and are completely under our company’s control. Now we can actually validate our solution in Analytics too, where we can indeed see that user identification and profiles are still working as expected, since otherwise each Page View would come from a new Unique Visitor, so all numbers would be equal:
Now that both the front- and back end show that everything works as expected, we can consider this experiment a complete success!
Conclusion
The process of bringing our whole Adobe Analytics implementation under the control of our own company is surprisingly straight forward. It clearly shows that Adobe has put a lot of consideration into each and every part of the chain, no matter if it’s Launch, the ECID service, or Analytics, so that we can configure everything in the way we did. It will be interesting to see how those proxied scenarios will work with the new Web SDK.
One thing that would be awesome to have in the future is something similar to how we handled Analytics and the ECID service calls, but for Launch instead. If we could configure Launch to run behind a proxy, we wouldn’t need to go through the hassle of having to manually download files or having them deployed via SFTP servers, which might be unfeasible for certain companies or setups. All we would need for that is two new fields in Launch, letting us configure the host and path where the proxy would point the libraries to. That would be a great feature!
But even as it is today, this first setup has been surprisingly simple to configure and validate. I hope you found this post useful and interesting. See you next time!
Frequently asked questions
There are multiple options. The most common solution would be to sign up for the Managed Certificate Program, which will hide the Adobe Analytics servers behind your company’s domain name. However, if you want more control and want to circumvent Apple’s ITP or ad blockers, you should consider using a reverse proxy as described above.
You can use the CNAME masking that Adobe offers in the Managed Certificate Program, but that will not save the Analytics cookies from being expired sooner. The only currently available solution would be to move the Adobe Analytics server behind a transparent reverse proxy, so that the requests are actually hitting your company’s own server.
If your only concern is the better looking domain name, then CNAMEs might be an option. If more control or Apple-compliance is needed, you should investigate the option to bring Adobe Analytics behind a proxy.
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.