Zero-rating marketing traffic
03 Oct 2021 » Mobile
As far as I know, all mobile operators impose data caps in their contracts. If you go over this limit, you may not be able to download anything else until the following month, may get a lower speed, may be charged an extra fee… This is in stark contrast with ADSL/cable/fibre providers, which generally offer unlimited downloads. In this situation, some companies feel it is unethical to have their visitors pay for any marketing activity they perform on their mobile website or app. I have even seen companies wanting their whole website to be zero-rated. If you are in this situation, here you have a few things you can do.
Who is asking?
The first thing to consider is what type of company has asked you to do that. When I first heard of this type of request, it came from mobile operators. However, over time, other types of companies have shown interest in zero-rating.
As you can imagine, this task should be very easy for mobile operators. They control the network and the billing, after all. They just need to configure their network devices and billing systems in such a way that connections to digital marketing domains are zero-rated.
The rest of the companies have it more difficult. They need to reach commercial agreements with all the mobile operators in their country, to pay the bill for these connections. Apparently, this is possible, at least, in some cases. YMMV.
Traffic to zero-rate
The next step is to evaluate what traffic should be zero-rated. The easiest way to list all this traffic is through a network debugger, be it Charles, Fiddler or your browser developer’s tools. This is a tedious process, as you will need to visit multiple pages of the website and behave like a typical visitor. Then, you will need to analyse all the calls you have made and identify those that you want to zero-rate.
If you are using the Adobe Experience Cloud, these are the domains that you should be looking for:
| Tool | Default domain |
|---|---|
| Adobe Launch | assets.adobedtm.com |
| ECID service | dpm.demdex.net |
| Adobe Analytics | *.sc.omtrdc.net |
| Adobe Target | *.tt.omtrdc.net |
| Adobe Audience Manager | *.demdex.net |
| Adobe AdCloud | *.everesttech.net |
| Adobe Campaign | Subdomain of your main website |
Limitations with domains
So, you now have a list of domains that you want to zero-rate. You may think that it is as simple as configuring a network device in the mobile operator’s network to scan for traffic going to these domains and log the amount of data consumed. This is what I said above, right? Unfortunately, it is not as simple as it seems.
Network devices only know of IP addresses (yes, I know, and TCP/UDP port numbers). Your website is likely to have a dedicated set of these IP addresses. However, most Adobe tools have pools of IP addresses shared between multiple subdomains. Besides, Adobe has various data centres scattered around the world, each of which has a different pool of IP addresses. This is typical for most SaaS tools, not just Adobe’s.
As an example, this is what I get when checking some Adobe IP addresses from my home in the UK:
$ host sstats.adobe.com
sstats.adobe.com is an alias for adobe.com.ssl.d1.sc.omtrdc.net.
adobe.com.ssl.d1.sc.omtrdc.net has address 54.195.254.128
adobe.com.ssl.d1.sc.omtrdc.net has address 54.220.133.225
adobe.com.ssl.d1.sc.omtrdc.net has address 54.74.170.177
$ host ags059.sc.omtrdc.net
ags059.sc.omtrdc.net has address 54.195.254.128
ags059.sc.omtrdc.net has address 54.220.133.225
ags059.sc.omtrdc.net has address 54.74.170.177
As you can see, two different subdomains resolve to the same set of IP addresses. If you were to zero-rate these IP addresses, you would actually be paying for all Adobe clients, including your competitors. Not sure this is what you want to do.
In the good old days, most web traffic was unencrypted and, with some extra logic, you could circumvent this limitation by reading the transferred data, not just IP addresses. HTTP data includes the domain name. However, nowadays, very few websites still run on HTTP. Google has pushed most of us to move to HTTPS, which means most traffic is encrypted. Network devices cannot see what data is exchanged and, therefore, cannot see the domain in the HTTP headers.
Use a proxy
The only solution I can think of is to route traffic to domains you do not control to a proxy you own. Then, with some simple proxy rules, send the traffic to the correct destination. For example, if you own domain.com, you could apply the following rules in the proxy:
| Tool | Proxy domain | Forwarded to domain |
|---|---|---|
| Adobe Launch | launch.domain.com |
assets.adobedtm.com |
| Adobe Analytics | analytics.domain.com |
<namespace>.sc.omtrdc.net |
| Adobe Target | target.domain.com |
<client code>.tt.omtrdc.net |
Since you own that proxy and you have control over its IP address, you can then zero-rate all calls to the proxy IP address.
You will have noticed that I have not included all Adobe tools in this last table:
- DMPs (like Audience Manager) and DSPs (like the AdCloud) alike require 3rd party cookies to work. If you use a proxy under your domain, these cookies cannot be set and, therefore, these tools stop working. If you want more details, the explanation I gave in my post 3rd Party Cookies & Server-Side Implementations also applies to this situation.
- The case of the ECID service is slightly different. If you know what you are doing, you can also use a proxy domain. However, there are side effects, the explanation of which are beyond this post. See the CNAME implementation overview help page for more details.
- For Adobe Campaign, there is no need for a proxy, as the marketing domain should already point to a dedicated marketing server.
In other words, for those domains that cannot be routed through your proxy, you either pay the bill for everybody or do not include it in your zero-rating request.
If you have a better idea, I would be more than happy to read about it. Please, leave it in a comment.
Photo by Scott Rodgerson on Unsplash