Open ericlucit opened 1 year ago
Pros and Cons
My initial thought is... this may be too hard for publishers, especially smaller pubs. I also suspect our larger publishers will have multiple registries - if they are operating in multiple countries for instance, or have different rating agencies based on different types of assets.
While this would be similar to ads.txt and some of the digital standards (which is attractive) I think the difference there is the publishers generally are web publishers (and even there, getting adoption I think has required a lot of education)
I think we might be better off focusing on standards for screen registries... e.g. if I have an id - is there a standard format (a la extended ids from the proposed IAB spec) and/or a standard way to resolve from that id to other metadata, and a core set of schema of what metadata should be available (maybe a super-set of the openrtb fields?)
I think we might be better off focusing on standards for screen registries
I agree - Because, the screen registries are the critical cog. And, if you get major companies to set up screen registries, the procedure for the actual operator (media owner) becomes pretty simple actually.
If you just had 8 companies : Lamar, Clear Channel, Outfront, Apparatix, Blip, Billboard Planet, Watchfire and Daktronics to setup registries.... You would cover nearly every Large Format billboard in the US. Because they already have the data..
And then, think about the small screens - If you have to get 75% of them, how many unique companies hold that data currently? -
And since they have the data - The screen registries would essentially be self-updating as media owners add and remove assets in existing tools... (this is the critical part - And why the initial screen registries would have to be deployed by the software company that is the primary source of truth for inventory from the media owner)
Then - Any customer of theirs, simply adds the TXT record as provided by the registry (the media owners already have an ability to update DNS because they do it already for Email, Google Domain Verification, etc. etc.)
And the beaty of it is.....the standard is Open and Discoverable - Meaning...anyone can host a registry - So there is no barrier to innovation from new companies and tech entering the space.
So - Yes, agreeing on an ID format (that provides discoverablity of the asset) coupled with a minimal screen registry standard, you have something that would work worldwide..
Again - using DNS will simplify the process of finding screens and finding the registries - You don't need a central "authority" of screen registries. You just use existing infrastructure and protocols that identify that a company owns an asset.
This proposal allows 1 or more screen registries, and allows a screen owner to decide who and where their screen registry is.
The screen registry provides a discoverable data set of screens that the screen owner wishes to make discoverable
Let's say we have 3 objects
Screen Screen Owner Screen Registry
Screen owner decides "who/where" is the screen registry for their screens by creating a special DNS
TXT
record on their domain that can be queriedThis
TXT
record contains a pointer to the DNS Endpoint of the Screen Registry that maintains the data for their screensFor instance
coolooh.com
may have a TXT record likeOPENOOH_REG=coolooh.myprovider.com/open-ooh-registry
This registry contains a set of interfaces that allow programattic partners to query it for data about
coolooh.com
's screensWhen
CoolOOH
goes to sign up forSome SSP
they simply provide their company DNS name - Based on this, the SSP can query assets for this companyThe standard we would then need to develop is
Then For any screen, they can be namedspaced with the name of the org that owns the screen.
com.coolooh.{someUUID}
The other great thing about this is, given any screen id like
com.coolooh.{someUUID}
an SSP or a DSP can discover information about that screen by querying the TXT record forcoolooh.com
and finding the Screen Registry service that contains the dataWhat happens when screen status changes? We can rely simply on HTTP status codes when you query the service for
com.coolooh.{someUUID}
301 Redirect
404
screen is gone forever304
not modified if you send an eTag and just want to know whether or not any information about this resource has changed503
could mean that the screen is offlineEtc. ETc.