Jampp created an app to test SKAdNetwork

From bidding to attribution, Jampp analyzed SKAdNetwork implementation by creating its own app. Here's how we became early SKAN adopters.

Jampp Team

February 2, 2021

iOS 14 & SKAN

From bidding to attribution, Jampp analyzed SKAdNetwork implementation with its own app.

As everyone in our industry knows, last September, Apple decided to temporarily postpone the launch of its App Tracking Transparency (ATT) feature1. As some are aware, this affects iOS marketing campaigns in several ways. This meant we needed to leverage the extra time to the fullest.

Our team set out to develop and test our solutions with SKAdNetwork, but most advertisers still weren’t supporting the required framework to start testing. In order to start testing ASAP, we launched our own app strictly for this purpose.

How to test a SKAdNetwork solution

We pride ourselves on our team of techies, and we love getting creative when it comes to testing. In fact, this was not even our first experiment. A few years ago, we also launched an app to evaluate the value of View-Through Attribution.

For our SKAdNetwork testing experiment to work, the app needed to meet certain criteria:

#1 Support the required framework
The app needed to be ready to leverage this initiative. Luckily, most MMPs automatically provide support for the SKAdNetwork framework with their latest SDKs.

#2 Have an integration with an MMP partner
We integrated our app with the tracking SDK of Singular, one of the leading MMPs. This allowed us to track Install and In-App event activity with SKAdNetwork, IDFA, and probabilistic attribution at the same time.

“Early collaborations such as the one with Jampp and their Birthday Buzzer app gave us confidence that we could provide advertisers with the most comprehensive SKAdnetwork solution possible. We’re working closely with advertisers and partners like Jampp to continue enabling data-driven marketing while staying compliant with new privacy standards. Our advice to advertisers is to start testing SKAdNetwork now to ensure you’re ready for this massive change.” — Jonathan Chen, Director of Product, Singular.

#3 Feature relevant content
If this app was to provide real results, it had to feature real content. An empty template made for the sole purpose of a test wouldn’t reflect authentic results.

We named the app Birthday Buzzer. It allows users to set up notifications for the upcoming birthdays of friends and acquaintances, and send them best wishes with e-cards.

Jampp's Birthday Buzzer app to test SKAdNetwork

The app groups all the special dates in one place. Users can add contacts both manually or automatically from their contact lists. We also added a list of pre-selected messages that users can copy and send on-the-spot.

The process

Building the app 📱
Once the app was approved by Apple and live on the App Store, we worked on growing Birthday Buzzer’s user base. To lead users to the app, we used our Dynamic Ads feature to create multiple ad variations of interstitials, banners, and native ads. We ran campaigns in three markets (US, Argentina, and India) to evaluate the performance in regions with different traffic and user behavior characteristics.

Testing SKAdNetwork 👨‍🔬
For our algorithm to run SKAdNetwork flawlessly, we performed a thorough analysis of our bidding pipeline, which involved:

Ensuring SSPs include our SKAdNetwork ID on the bid request
Implementing support for SKAdNetwork objects in our bidder
Making sure that clicks with the SKAdNetwork framework can be tracked properly
Receiving SKAdNetwork postbacks from Apple, processing them correctly, and ingesting them in our ML models.

The results

Early on, we noticed that we weren’t receiving all the expected SKAd values, but it turned out this wasn’t on our side: Apple’s solution was buggy. It wasn’t until November that Apple finally announced that the source-app-id and conversion-value parameter values were now available in the install validation postback.

SKAD traffic availability is still low: some SSPs are still working on adding SKAD support on their SDKs, and those who already have it are experiencing slow adoption from publishers. So far, we are seeing SKAdNetwork support in approximately 15% of the available iOS traffic.
The struggle is real: SKAdNetwork’s random timer and updates on conversion-value introduce delays, causing postbacks to arrive days after a user’s conversion. This delay in the postbacks can disrupt machine learning models and campaign optimization. Advertisers need to work closely with DSPs to fine-tune their conversion value mapping, enabling optimizations and improving the signal speed.
There is (more than) hope: the results of this experiment were encouraging: click to install conversions were similar to MMPs’ IDFA attribution values. However, this doesn’t mean the results will be the same for all campaigns. Testing and fine-tuning SKAdNetwork requires a lot of effort on behalf of each advertiser. Results are closely related to how much work goes into re-defining conversion values, which are based on marketers’ unique KPIs and goals.

What still needs to be done?

As DSPs and tracking partners join forces to meet this new challenge, there’s still a lot of advertisers and publishers can start doing.

On the advertiser side:

Implement both the App Tracking Transparency and the SKAdNetwork frameworks. Talk with your MMP and make sure you update to their latest SDK version.
Optimize your opt-in messaging. Work with your Product team to test opt-in alternatives based on the user journey. You can start by A/B testing different copy and time-of-day placements for the pop-up message. Focus on educating users on the value they get for sharing their data.
Focus on your conversion values. SKAdNetwork has its limitations, one of them is the fact that the app will not be able to send multiple in-app events and revenue data points to inform all your growth channels—it will send only 6 bits of data.
Advertisers can work with independent frameworks or directly with their MMPs to leverage those 6 bits to map conversions. This isn’t easy, but it’s not impossible. Many models can be adopted, so talk with your Product team to select the one that best works for your business and KPIs.
Test LAT traffic: besides implementing SKAdNetwork, marketers should also start testing LAT (Limit Ad Tracking) traffic in advance. In fact, the more marketers start experimenting with LAT traffic, the more prepared the industry will be for iOS 14.

On the publisher side:

Increase SKAdNetwork adoption: while SSPs have been releasing their latest SDK versions with support for SKAdNetwork, publisher adoption is still low. To test the framework at a larger scale on all the relevant buying channels, we need more publishers to start supporting this initiative.
Set up differentiated waterfalls: by creating a waterfall featuring device IDs and one without them, publishers will be able to A/B test and conduct optimizations once the changes in iOS 14 are live.
Test the message: publishers will be able to gate users’ consent behind their own messaging system. This means that by setting up, testing, and fine-tuning their user consent messaging, publishers could and should try to get more users to opt in.
It’s specially important for publishers to be up to date with Apple’s latest changes since they will have much more responsibility in the post-IDFA world. As WeatherBug’s SVP put it: “Apple goes out of its way to state that publishers are responsible for any third-party code they place in their app. If an SDK combines user data from a publisher’s app with user data coming from other developers’ apps to target or measure ads, that counts as tracking – even if the publisher doesn’t use the SDK for those purposes.”

Want to learn more?

If you’re looking to start implementing SKAdNetwork, get our iOS 14 guide for app marketers, or contact us to launch your user acquisition and app retargeting campaigns with a partner that’s ready for the post-IDFA world.