How to Catch & Kill Mobile App Store Redirect Ads

We’ve all seen them; you’re casually browsing your favorite app or playing a game on your phone and suddenly you’re being redirected to the app store to download Candy Crush.  What gives?  It’s another obnoxious mobile app store redirect ad that’s automatically sending you to the app store without a click.

These are the pop up ads of the mobile age and virtually everyone hates them, including the chain of mobile publishers, exchanges, and other ad tech that unwittingly served them in the first place.  But they can be quite difficult to find; because no one wants to serve them they are purposefully targeted and served in a way that makes them difficult to replicate. TechCrunch wrote a good overview of the complexity of this problem in 2015, and also linked to Sergei Frankoff’s detailed technical description on the Sentrant blog of how frame-busting JS combined with 302 redirects was able to automatically open the app store.

Below is a step-by-step guide designed for ad operations teams to demonstrate how to use Charles Proxy to identify and eliminate a mobile app store redirect ad, though it unfortunately won’t act as a detection system or a blocker of any kind. Thankfully most exchanges have found ways to ban frame busting code like the one mentioned in the TechCrunch article at this point.

Step 1: Start recording your web traffic with Charles Proxy

Charles Proxy is a program that will sit between your browser and the internet and record all the different interactions when loading a web page, even those you can’t see in the source code.  The benefit of using Charles is it doesn’t matter how fast the page redirects or how many parties are involved in the process.  Charles will record everything and let you meticulously search through all the interactions at your own convenience.  It has a free trial version, but if you work in ad operations you should just buy a license.  The tool is essential for all sort of debugging needs, and a license is just $50.

Step 2: Catch a redirect to the app store by navigating through your app

This is the hard part.  Mobile app store auto redirect ads are typically frequency capped, targeted in obscure ways to avoid detection, and are difficult to replicate.  If you’re having trouble, see the Advanced section at the bottom of this article for ways to speed up the process.  Make sure you leave Charles Proxy recording your traffic, since you’ll search through the results to find the root source of the mobile app store ad. I’m not trying to pick on Candy Crush here in particular either, they’re just a popular example these ads point toward.

Step 3: Search your Charles session for ‘iTunes’

You could do the same for the Play store on Android – the vulnerability these auto redirect ads have is they all have to point into the app store eventually, which makes them easy to search for in a Charles session.  I’m going to blind the domains and identifying elements of the publisher and ad tech vendors in this example because the specifics don’t matter.  It won’t help you identify the problem on your own site, and I don’t expect th companies involved in this particular redirect are willing participants.

Step 4: Find the Referrer

Double-click the ‘Response Header’ result in Charles and bring up the full details of the request using the Contents tab.  Now you can find the Referrer, which is the ad tech company responsible for serving this ad. As a final QA step, render the link to the iTunes store by pulling the Location value from the Headers tab.  Remove everything from the URL after the ID value, and then replace ‘itms-apps’ with ‘http’ in a desktop browser window and fetch that page.  It should match the app you were initially redirected to.

Step 5: Use the Overview tab to find the full URL of the request

Here’s where you can find the first helpful piece of the puzzle; it’s the link that your browser called which triggered the redirect.  Be prepared though, this might be one of many redirects you have to sort through until you can identify a partner you actually work with as a publisher.  But, this is your initial proof, and will let your downstream partners eliminate this tag from their system.

Step 6: Double-click on the URL value to find the relevant parameters.

Copy this – you can try to render it in your browser as well, but you may find that it doesn’t work now that you’ve already been redirected to the app store, or that it won’t work outside your app.  Still, your ad tech vendors will need this info.

Step 7: Find the line item in your ad server which ended up causing this redirect

You can locate these values by looking at the response from your ad request; in most cases ‘securepubads.doubleclick.net/gampad/ads’ as seen here. You can see the line item ID in the google-lineitem-id field in the header section of the response.  In this case it was either line item 202980995 or 186319955 which served the offending ad.

Step 8: Shut off your problematic line item

With the relevant line item in hand, go into your ad server and suspend that tag and notify the downstream vendor.  This could be a financially painful decision in the short term as you may need to exile an entire exchange or network while the root problem gets fixed.

Step 9: Save your Charles Proxy session

Now that you’ve done the hard work to find your smoking gun evidence of the app store redirect, make sure you save your Charles session so you can forward it upstream to your demand partners.

There are probably many companies involved in a long redirect chain, and each one will need specific campaign identifiers to locate and suspend the problem in their system.  Your Charles session has all those details contained in it, even if you don’t necessarily know how to find them, and will help everyone move much faster.  To give you a sense of the complexity you may encounter, in this particular example the app store redirect was 7th party served – gah!  Meaning that after the publisher ad server (the 3rd party), there were four redirects between different platforms before the app store redirect.

Step 10: Send all evidence, including trigger URL and Charles Proxy .har file to the vendor serving the redirect.

Now you’re at your vendor’s mercy to kill this tag from their demand, and candidly you’ll just have to take their word for it that they’ve fixed the issue for the time being.  Thankfully you’ll have provided a mountain of specifics for them so they won’t have to chase it down themselves.  Just suspending a tag or blacklisting and advertiser on a specific account is typically dead simple.

Advanced Tips

Know an app store redirect is out there but can’t replicate it?  Use the Repeat Advanced feature to automate some test ad requests, or requests to specific vendors themselves.  Then, search ‘iTunes’ again in this separate session from the list until you identify an issue. You can read a full walk through of this feature here: Advanced Charles Proxy Tutorial.

App Store scammers are smart; they’ll try to make it as difficult as possible to identify their ads, which is why they hide them in so many redirects.  Other common tricks are to frequency cap at one per lifetime, so that once you’ve seen the redirect you can never find it again and to target older models and operating systems.  Fortunately you can use Charles to spoof virtually any combination of user agent / device, but it may also mean you have to try a wide variety until you find one that works.  Finally, scammers often target just cellular traffic, which is more difficult to inspect than WiFi or Desktop.  Again, there’s a solution with Charles, but it is a bit more complex to setup.  You can read about how to do it here: Charles Proxy on Cellular Networks.

Have other tips or suggestions on how you identify mobile app store redirect ads?  Share them in the comments so we can work together to eradicate these awful ads!

Source

How to Catch & Kill Mobile App Store Redirect Ads