The Reason for increasingly poor conversion of paid channels on mobile (4/7)

A common phenomenon is that mobile traffic converts worse than desktop traffic. There are dozens of articles (or here) and extensive studies on the net.

The difference is often explained by the fact that the screen is too small and navigation is difficult. The user likes to get information on mobile, but then switches to the desktop device and makes the purchase. This is the so-called “cross-device problem“. In this article I would like to not only talk about this problem, but especially about the rather underestimated “cross-browser problem”.

Getting to the bottom of the problem – step by step

Most people in our industry have already heard about the “cross-device problem” – but very few are aware of what exactly happens and what side effects it has. I would like to illustrate the problem with an example:

…from here comes the big question mark. Very few users synchronize their browsers, so that visited or called browser tabs appear on the desktop device. How does the user get to the shop and the product he wants to buy? There are several possibilities:

1. He enters the URL of the shop directly in the desktop browser and searches for the product again.
2. He “googles” the shop name (possibly + the product)
3. He sends himself the link to the product (e.g. via e-mail, note sync etc.)
4. He tries again to find the display he used to get to the shop (in my opinion unrealistic)

They all have one thing in common – when the user visits again (this time via desktop), he is a new user with a new session for GA. And to which channel is it assigned? Well, that depends on which of the options he uses – in my opinion, variants 1 and 2 are the most realistic, i.e. Direct or Search. In any case, it’s not the display channel. So when the user makes a purchase, another channel is “strengthened”, while the actual channel is weakened in conversion (Impression yes, Sale no).

This effect increases the higher the mobile share of a company is! Conversely, the more mobile traffic you buy, the more you subjectively weaken your paid channels.

Granted, it is very complicated and technically extremely challenging to solve the “cross-device problem”. From the big providers (Facebook & Google) there are approaches with the so-called “Cross-Device-Tracking”. These are based on the fact that the user is logged in on both devices, Facebook or Google, and is therefore identifiable. This can help, but inevitably leads to wastage, since not every user is always logged in everywhere.

In addition, the question arises how Google handles cross-device visits that perform a Google search after the device change to get to the shop. Does it stay with “Display” or does Google count the cross-device user as “Organic Search”? And what if the user clicks on an AdWords display of the shop instead of the organic hit? Is it then treated as “Paid Search”? Unfortunately I could not find anything on this topic in my research.

The underestimated problem: InApp browser

In the course of my research I also came across a little-known problem with the so-called InApp or Webview browsers in iOS and Android, see “In-App Browsers: What You Need to Know” or “The Facebook browser – the biggest browser that you ignore“.

An InApp browsers is a browser framework that mobile apps can use to call external pages directly from the app without leaving the app. Apps like to use this feature because the user stays in the app and they keep control over the user and his surfing behavior (especially since they can use advanced tracking capabilities natively in the app).

Among the most popular apps that use this feature are without doubt Facebook, Twitter and Instagram. But also many other popular apps like Telegram, LinkedIn, Xing and many others use InApp browsers.

Why are InApp browsers bad for the user?

Unfortunately, InApp browsers have some negative properties for the user, including:

• There are no tabs – everything takes place in a browser window.
• The URL bar can be deactivated by the app provider, so the user cannot simply enter another URL and continue surfing. He can only navigate with links on the opened page.
• It is not possible to access favorites, i.e. neither save nor retrieve them
• Usually no browser plugins work (e.g. password manager like 1Password)
• You have your own cookie storage (more about this later)

All this makes InApp browsers rather unpopular for users. The consequence: Users use the offered function “open in Safari/Chrome” to switch to the standard browser of the smartphone. Unfortunately, important information for attribution is lost and there is a risk that the user is counted twice (see also “Unique Visitors In A Multi-Device World“).

InApp browsers lead to a “cross-browser” problem

As already mentioned, InApp browsers have their own cookie storage – i.e. cookies that are already set in the standard browser are not available in the InApp browser! Conversely, cookies that are set in InApp are also not available in the standard browser. In addition, each InApp browser is almost completely isolated from the other – in other words, cookies that are set in the Facebook InApp browser are also not available in other InApp browsers (e.g. Twitter). This results in a “cross-browser” problem, similar to “cross-device”.

And this is exactly what causes some attribution problems! Let us imagine the following scenario:

A shop places a product ad on Facebook. A user sees the ad in the Facebook app, clicks on it and is forwarded to the shop in the InApp browser. The redirection takes place via an AdServer including a cookie switch. The user therefore receives a cookie from Facebook, from the tracking provider of the shop, and from the shop itself. UTM parameters were used on the landing page, which is why the user was also correctly recorded in Google Analytics. So far, everything is fine – if the customer completes his purchase in the InApp browser, there are no problems at all.

Scenario 1: Customer jumps right out

However, it becomes problematic if the customer decides to switch from the InApp browser to the standard browser. If he does so, the last open URL is called – in the above example, this includes the UTM parameters. This is where things get complicated: When “jumping out” all cookies are lost – they cannot be read by the standard browser. The cookie from Facebook and also the cookie from the tracking provider that controls the cookie switch were only triggered by InApp. For the shop and also for Google Analytics this is a new user – ergo a new cookie is created and a new session is started in GA. Although GA tracks the correct origin based on the transferred UTM parameters, the same user was thus recorded twice. If the customer now completes his purchase, the shop triggers the tracking pixel of the tracking provider – provided that the customer uses the tracking container based on the cookie switch from the provider. However, the cookie is no longer present in the standard browser (only InApp was triggered) – i.e. the conversion tracking pixel from Facebook and all other possible tracking pixels in the tracking container are not called up!

Scenario 2: Even worse – customer navigates in the shop first

Let us imagine the customer who clicked on the ad and InApp does not jump out immediately in the product detail. He first navigates InApp within the shop – he visits a cross-selling product, for example, or performs a search or puts something in the shopping cart and calls it up. Only afterwards does he select the function “Open in Safari/Chrome”. In this scenario, the UTM parameters are also lost – these are usually only attached to the landing page URL, but are not taken over during further navigation. Result: In addition to Facebook and the tracking provider, the shop and GA also lose the user’s origin information! In GA, the customer is therefore recorded in the direct channel (if GA cannot recognize a referrer in the fallback case).

But how often does that happen?

Unfortunately, it is not possible to determine how big the InApp problem is. I could not find any information about how many users are using the “Open in Safari/Chrome” function. But in a small survey among the everysize employees and my acquaintances surprisingly many use this function. 9 out of 20 stated that they “also often” or even “always” do so. Surely this number is not representative – but even if only 10% of the users jump out of the InApp browsers, this would mean that the paid attribution would differ by 10%!

How can the problem be solved?

Unfortunately, there is no simple solution to the cross-device or cross-browser problem. With cross-device tracking there is at least one approach based on logins. Here the user must be logged in on his mobile and desktop device. The best known logins are undoubtedly Google and Facebook – and probably Apple in the near future. Furthermore, there are so-called login alliances such as netID or Verimi. However, success depends on whether one can motivate the customer to log in on both devices.

Unfortunately, the cross-browser problem is even more complicated. Since each InApp browser has its own cookie storage, the user must also log in again in each app within the InApp browser (but only once per InApp browser). However, it is questionable whether the user is motivated enough to do this permanently – especially since InApp browsers always act like a kind of “temporary browser”. I myself assume that this is rarely the case and if so, then at most for Facebook, Google and amazon. The user rather jumps out of the InApp and from there on the recognition – without login – is difficult or impossible.

During my tests I found out, for example, that InApp browsers usually use their own, slightly modified user agent that points to the corresponding app.

With Facebook, for example:

Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_5 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Mobile/15D60 [FBAN/FBIOS;FBAV/157.0.0.42.96;FBBV/90008621;FBDV/iPhone9,1;FBMD/iPhone;FBSN/iOS;FBSV/11.2.5;FBSS/2;FBCR/Verizon;FBID/phone;FBLC/en_US;FBOP/5;FBRV/0]

and at Instagram:

Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_5 like Mac OS X) AppleWebKit/604.5.6 (KHTML, like Gecko) Mobile/15D60 Instagram 31.0.0.14.97 (iPhone9,1; iOS 11_2_5; en_US; en-US; scale=2.00; gamut=wide; 750×1334)

With this (and because of other differences in the browser engine) fingerprint tracking is not possible – if you want to test this yourself you can visit amiunique.org once in your default browser and once in an InApp browser:

This means that both cookies and fingerprinting are not required for attribution. This leaves only the IP, which in times of shared IPs is definitely not a unique identifier and therefore not suitable for attribution.

Addendum: deviation greater than expected

There are 4 weeks between the initial writing of this article and publication. During this time I have tried together with two everysize dealers to find out how many conversions are lost due to the “cross-browser problem”. Since we have a very high mobile share on everysize and use different paid channels, my estimate was 10-15% (meaning: conversions that were not assigned to everysize but ended up in the “direct” channel).

Together with the dealers, I therefore carried out various comparisons – then we statically extrapolated the result. The result: 25 or 30% of the conversions generated by the channel everysize ended up in “Direct”!

Of course I am aware that this is only an extrapolation and that the values are not 100% correct. There are simply too many variables that influence the statistics (touchpoints in the customer journey, other factors that influence faulty tracking, etc.) But that InApp browsers have a negative influence on the attribution is in my opinion undisputed.