Why Data Exchange Must Change?

Data exchange must change

Why data exchange must change

INITIATION

Data exchange must change: One of the most outstanding used landscapes of the Adjust Dashboard is setting up a partner module to share install, session, and event data.

In most cases, partners require all your app data sent, not just its associated traffic. It is your organic data as well as data associated with other networks. And while Adjust itself does not share attribution information between networks, this sharing gives those partners visibility into your overall user base.

Let’s talk about why it’s the status quo and why it needs to change.

 

PART 1

Between the devil and the big blue

If you ask a network partner why you need to enable a module to share all your installs with them instead of the traffic they generated, the first answer you’ll hear is exclusion targeting.

The idea is elementary. It turns out that people who like your app also want to click on your ads. Since many ad servers optimize click-through rates over install rates, you can end up spending a lot of money serving ads to your already engaged user base.

An ad serving partner only needs to exclude these people from their targeting; in short, targeting by exclusion.

To share the data, your network partner must make this exclusion. The current de facto standard is to trigger a stream of real-time callbacks on their backend.

From this stream of unique events, partners generate a list of active devices already using your app.

Precisely?

The problem is that the real-time streaming features only work if enabled reminders. Previous installations will not carry over. It means that most active users had already installed a typical application before reminders activating.

How valuable is exclusion targeting when 90% of your existing users don’t know?

Your network partner is telling you that there is a simple solution to this problem. Just send your session details to see who is using the app. They say this will significantly improve the reach of their blocked list.

The two currently favored solutions, therefore, have unacceptable disadvantages. Is there no other way?

 

PART 2

In a perfect world

Before facing the harsh reality, let’s discuss the ideal solution.

When we share an audience with a partner, we want to share as little information as possible and update segment changes automatically and in real-time. This way, an affiliate will not use our user list for other purposes while still having an up-to-date audience.

Optimally, we could partition a list so that no one can pull all devices from it, only a yes/no if a specific device ID is there.

For example, we don’t want to share any information about a user who previously had the app connected regarding exclusion targeting.

 

But how close do we get to the optimum?

 

PART 3

 

In the real world

If we break down our optimal solution into various aspects, we can see where it clashes with the real world.

 

Can we part a list without division a list?

To reply to this request, we first need to understand how device identifiers such as (for example) the IDFA through the advertising ecosystem. Each time a device requests an ad impression, the party serving the ad receives the IDFA and can decide which ads to help on the device. At the same time, nothing prevents the ad server from storing the IDFA and some primary data such as country, working system, and device type. Even if the network has no bad intentions, it still has to store the IDFA to remember which advertisements it has seen on this device and how many times.

Some exciting new advances in cryptography could make such a scenario possible in the future. However, the main hurdle for this will be the operating system, which must support the generation of specially encrypted device IDs for anything other than the app publisher.

When do we accept that we can’t keep the user list away from the media partners we work through.

Despite this sobering fact, submitting a raw list of device IDs is still a significant improvement over the status quo. Instead of sharing a potentially incomplete and therefore inaccurate list of users or disclosing session data of your entire user base, you can share the minimum list of devices you should exclude from campaign targeting that you have configured.

For example, if you’ve decided to launch a campaign targeting iPhones in Japan, all you need to do is share a list of devices that match those criteria. Compared to the alternatives, this is an improvement.

So if allocation device ID lists are so much better, what do you need to do it?

CONCLUSION

How do we get there?

First, you need to create a list of devices that meet specific criteria. Ideally, this generator would automatically update such an audience without additional manual input.

Then you should be able to share and update your list with the network partner of your choice.

There are two universal ways to share audiences with ad servers. Either via a push API provided by the partner or via (e.g.) URLs shared raw lists that partners can use as a pull API for updates at regular intervals.

Coincidentally, Adjust’s audience builder can do just that. You can create and share audiences based on any criteria in real-time with many of your current traffic partners.

With extra and more regulars asking us to help them reduce excessive data sharing, we decided to expand the Audience Builder program significantly.

Adjust will soon add all of our currently available partner push APIs and work with those who rely on our pull API to engage the public.

While many partners still need to update their systems to use audiences in this way, we believe advertisers can drive this change by demanding a better way to share their data.

AlsoRead: Best Budgeting Apps 

techthread

Leave a Reply

Your email address will not be published. Required fields are marked *