This blog is pretty niche. I sort of wanted it that way when I started, and since I love my niche to bits, there has never been a reason to change.
What I write about today, though, is a whole new level of niche. This article, I am sure, will NOT push that s_code overview off the throne.
Today is about using a reverse proxy as your tracking server.
Let me draw that.
While Analytics tracking calls usually go straight to one of the nodes of the Adobe infrastructure, in a deployment with a reverse proxy, they go to the proxy, which calls the Adobe tracking server in turn.
There are maybe a dozen or so deployments in Europe who use this technique, and the top two reasons have to do with privacy regulations.
A reverse proxy allows you to modify the tracking sent by your visitors. Possible modifications include:
- (partly) removing the visitor IP address,
- adding an “internal” flag to visitors in your own company,
- removing sensitive data from the tracking call (as a band-aid quick fix!)
With a reverse proxy, you can also implement a ‘kill switch’, i.e. completely stop tracking for some or all visitors.
And, finally, if you are a company in Russia, a reverse proxy within Russia may simply be required.
There are disadvantages, too, of course!
All tracking will go via your infrastructure, meaning that a) you must provide said infrastructure, and b) for some far away visitors, tracking is slower than normal, RDC-based tracking.
If you wonder whether a reverse proxy could do the job of VISTA: it could, yes, but the visitor can in some cases see the modifications you make, so don’t use this mechanism to add things like cost of articles!
The proxy can be easily built using an Apache HTTP Server.
The below, added into your
httpd.conf, would enable proxying, including removal of the last octet of the visitors’ IP addresses.
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_connect_module modules/mod_proxy_connect.so
ProxyPass / http://xyz.sc.omtrdc.net/ retry=60 ProxyPassReverse / http://xyz.sc.omtrdc.net/ retry=60 ProxyTimeout 20 # remove last octet of IP address RequestHeader edit X-Forwarded-For "^(.*)\.[^\.]*$" $1.0
First things first: this approach does not work for the Experience Cloud ID Service!
It is also not the best idea to use this technique for Target.
Although it would work, the proxy would introduce latency. Target being all about showing things to your visitors, any delay would be detrimental.
6 thoughts on “Quick Tip: Using a Reverse Proxy with Analytics”
Thanks for the article. I worked with implementation based on reverse proxy. Good that it is gone now. It was used in order to anonymize IPs before data leaves the country (Switzerland). Then law or its interpretation has changed and company was good with “anonymize IP” setting in Analytics configuration. It is hard when communication with IT is not good: server issues, config changes etc. However, from learner perspective this was something (especially issues!) that really helped me to progress a lot with the technical (dark) side of the force!
Absolutely agree: doing the sh*tty things really helps you understand how stuff works.
I just changed the chain, forward crankset, and chainrings on my bike. Dirty as hell, but I now know a bunch of things about gears and how the force is transmitted from my legs all the way to the tires.
Hi Jan, could you expand a bit on the reason for this not working with the ECID Service? Thanks, Alex
I think that is another article. Starting that now…
Hi Jan, could you give a bit more detail on why this doesn’t work with ECID Service? Thanks, Alex
That is a big and interesting topic, which I want to cover in a separate article at some point.
Bear with me…