How programmatic advertising would work?

[jmrodriguez-smartclip]

Hello, and sorry for jumping out of nowhere...But the approach taken in Pigin is something i've been thinking about too (shifting where "segments" are stored, from the DMP, to the browser itself).
In fact, i think there are two "possible" levels (note: i didnt say "factible" levels):

• To store the segments in the browser, and send them to a third party, which matches "server side".
• To do the whole "matching" in the browser: It's not the browser the one sending the interest groups to third parties, but the third parties providing the browser in which interests groups are interested, and the browser responding with the matching interest groups.

But i always fail in figuring out how would this apply to programmatic advertising. In the example shown in the documentation, there's a direct relationship between WeReallyLikeShoes and RunningShoeReviews.com. They have an agreement. And, if both parties know each other, in many cases, there's even no need for cookies or id matching.

But how does this work in a programmatic environment?
Scenario:

• I buy something for a foreign e-Commerce site, A.
• A adds me to its own private interest group.
• Then i visit a local newspaper site, B, which allows reading of its own private interest group, to its adserver.
• I guess that all possible interests groups where the adserver is allowed as "reader", are eligible to be sent to the adserver.
• That adserver was not included by "A" as an allowed reader of its interest groups (because that would mean that A should add all possible adservers as readers).
• If some sort of delegation is in place (and resolving all the chain of delegations, before requesting an Ad), the "private interest group" where A added me, is eligible to be sent to the adserver (and follow all the delegation chain up to wherever site A is buying inventory).
• But, to include the interest group where site A added me, in the list of headers sent to the adserver, site A must compete with all the possible sites i've ever visited that ever allowed the adserver to be a "reader" (and most of them, are not running any campaign, as they used the adserver just to ask for ads, so nobody is targeting those interest groups)

I sincerely may be wrong there, as i dont think i still grasp all the details of the PIGIN proposal.
Feel free to correct me everywhere it's needed.

But i think a key goal of any possible proposal, should be that the method proposed, should be the only possible existing method. This is, if PIGIN exists, but cookies also exists, it'd never have any success. But also means that PIGIN should be, in all use cases, even those out of the scope of preventing user profiling (for example, in ad tech, frequency capping). This kind of use cases should also be described.

But let me share a possible different approach (which is also very very rough).
A possible answer to the question "why is user profiling even possible", is that it's allowed to store lots of information, to all possible actors involved in rendering a web page, and information that can be mapped between different actors (cookie matching).

What would happen if the amount of information stored for each actor, is not the same, and, for any third party, even in the best scenario, that amount isnt enough to even store a reliable "user id"?
So, for example (again, very rough):

• Any first-party domain, is allowed to store any amount of data as cookies.
• An iframe of a third-party domain, included directly inside a first-party domain, is only allowed to store, at most, X bytes. Those bytes are related to certain "vendor ids", and that storage should be so small that it's most reasonable use case would be storing "flags". What meaning has those "flags" is completely dependent on who stored it.
  This is, an e-Commerce could use in its "allowed storage", bit 1 as "Visited shoes", bit 2 as "Visited electronics", but not much more.Those bits are only meaningful to this e-Commerce, and, from time to time, they would change their strategy of assigning bits (during some months, they're interested in people who buys shoes, so they use all their storage bytes to save info about shoes. A few months later, that changes, and the whole strategy changes).
  If the information stored is limited, and changes over time, i guess profiling would be very difficult, as you cannot simply mix and match data from different sites, or even match with the same data from some time ago.
  By limiting the amount of data stored by each "vendor", maybe hashing it with vendor-provided keys,etc, the bitset representing all the data all vendors have stored in my browser, could always be shared, as they would be encrypted, and, even if decrypted, what means each bit of data, is something only each vendor, in a point of time, knows.
  Also, the browser could impose limits: Only send data from the last (say) 100 vendors seen.

A possible extension would be that, as we descend deeper and deeper into the third party iframes structure, the number of bits "visible" to vendors, gets smaller.

So, eCommerce A, when i'm visiting site A, can write any traditional cookie, and at the same time has access, via API, to its "vendor-id related" storage.
If eCommerce A shows me an ad, directly from my adserver, it'd still have access to the complete "vendor-id" related storage.
If eCommerce A shows me an ad after my adserver redirected to another one, eCommerce A has access to X - Y bits of their storage (losing precision at the same time they go deeper in the chain).
Maybe, the request to adservers would be authorized to receive the full storage data (so matching is always done over the full storage data), but any third party code, would receive the clipped data.So, matching capabilities are not lost, but profiling capabilities gets narrower.

Very rough, a different approach...Who asked about my opinion anyway?
But , well, let me just waste some of my time! :-D

[jmrodriguez-smartclip]

And, btw, another possible extension would be that the user chooses how many bits of storage allows to third parties , being paid for that (an advertiser could bid for storage space on the user device,as there would be a max space available,and in many cases this would have lower costs than a DMP), shift the perception of online advertising , and allows advertirsers to bid differently on impressions depending on the willingness of the user on accepting data.
As the bitmask is actually a taxonomy, no DMP is needed, and targeting (from the adserver perspective) is simpler, as it's not needed to test if an user belongs to a (gigantic) segment. It just needs to AND the data with a mask.
I agree the management of data in this scenario is complex, and that many use cases for cookies are not covered...But imho this kind of approach has its upsides