Data import, or Pingback/pixel url, instead of a prefix?

[kookster]

I work with a number of shows experiencing "prefix fatigue", and I'm interested in how to still allow them to choose to provide data to op3 without having to add yet another prefix.

What do you think about either allowing a file export/import as a way to get data from a host, or for DAI-style hosts that support calling 3rd party pingback/pixel urls with request information, what about an endpoint for op3 to deliver data per request that way?

[johnspurlock-skymethod]

It's a good point about the proliferation of multiple prefixes. Prefixes are still ideal for OP3 in particular for a few reasons:

• Client rough geo dimensions (country, state, metro) provided at request time by the cloud platform, no need for an external lookup-by-ip-later 3p service (OP3 does not call out to any 3p data enrichment services)
• Independent from the host and bound to actual requests, not subject to delays/omissions/etc, and does not require integration work
• Results are comparable across shows since the mechanics/methodology is the same

I try to make OP3's prefix very easy to add, no login/signup/unique-show-code required - but I agree it's not ideal to add yet another prefix, especially when it has a temporary impact on download numbers as some apps re-download.

One interesting idea I heard that might be a future solution is to have a single clearinghouse "1prefix" service, that would call out to multiple provider downstream services. Would have to be funded/run by an industry consortium, but would be simple+transparent from a tech point of view - and perhaps even make the data sharing agreement workflow easier as well. Could limit attributes to send to which providers etc. Downside would be single point of failure, trust - but I believe there are existing analogues in the ad bidding space.