Conversation
|
|
||
| ## Request Change | ||
|
|
||
| This community extension defines how Agentic Audiences embeddings are conveyed in OpenRTB bid requests. The extension uses the existing `Data` and `Segment` objects in `BidRequest.user.data`. Each data provider supplies one or more segment entries, where each entry is a vector embedding with metadata describing its type and model. |
There was a problem hiding this comment.
Community extensions use ext fields, so all these extra fields should hand off user.data.sement.ext if you're going to use segment
| # Agentic Audiences in OpenRTB | ||
|
|
||
| **Sponsors**: LiveRamp | ||
|
|
| "data": [ | ||
| { | ||
| "name": "live_ramp", | ||
| "segment": [ |
There was a problem hiding this comment.
The next five fields should hang off ext not segment directly or this isn't an extension.
Also according to the aa spec this is rather incomplete
There was a problem hiding this comment.
i fixed it so that the aa specific fields are under ext. in regards to the incompleteness.
these were the minimum ones we thought would be needed in openrtb.
do you believe we should add all fields in the aa spec? are you concerned with request size bloat?
There was a problem hiding this comment.
I am worried about that but the appendix audience spec says a bunch of fields are required and then it lists even more optional fields, so I'm not sure which is right
There was a problem hiding this comment.
The aa spec's required fields could be pruned down a bit. Also the original spec was meant to cover the targeting side as well, for example metric specification isn't as relevant on the supply side.
There was a problem hiding this comment.
we can:
- we move forward with this small set of fields and add more as needed
- we make it follow the AA spec exactly, including nested fields and long form names
There was a problem hiding this comment.
@adam-zimmerman @patmmccann i think we should move forward with #1 and add fields as needed by the community
There was a problem hiding this comment.
Okay but then you should change the aa spec to move more things to optional
| "user": { | ||
| "data": [ | ||
| { | ||
| "name": "live_ramp", |
| "name": "live_ramp", | ||
| "segment": [ | ||
| { | ||
| "ver": "1.0", |
There was a problem hiding this comment.
The spec calls for much longer vectors and the arrays of floats would require much more precision than one decimal place. I think this example is misleading. It is likely wise to use a better data structure than this vector spelled out so poorly compacted
There was a problem hiding this comment.
moved to ext but this is for version. so version of the model that was used to generate the embedding. not the actual vector or array of floats.
There was a problem hiding this comment.
Yeah I meant the line below, looks like we already came to agreement ty
| "segment": [ | ||
| { | ||
| "ver": "1.0", | ||
| "vector": [0.1, -0.2, 0.3], |
There was a problem hiding this comment.
Maybe something like this instead?
const floats = [
1.2345678, -2.5, 0.0, 3.1415927, 12345.678,
-0.00012345, 42.42, -999.999, 0.000001, 987654.25
];
function floats32ToBase64(arr) {
const buffer = new ArrayBuffer(arr.length * 4);
const view = new DataView(buffer);
arr.forEach((x, i) => view.setFloat32(i * 4, x, true)); // little-endian
const bytes = new Uint8Array(buffer);
let binary = "";
for (const b of bytes) binary += String.fromCharCode(b);
return btoa(binary);
}
console.log(floats32ToBase64(floats));
// UQaePwAAIMAAAAAA2w9JQLbmQEZbcgG5FK4pQvD/ecS9N4Y1ZCBxSQ==
There was a problem hiding this comment.
you're proposing that instead of an array of floats, that the array is encoded to base64. is that to reduce size of the request or is there an issue with just transporting an array of floats?
There was a problem hiding this comment.
Just to reduce the size, the spec talks about it being 512 or 1024 entries long
There was a problem hiding this comment.
I was also thinking the array itself should be base64 encoded
There was a problem hiding this comment.
@patmmccann @adam-zimmerman i went ahead and changed vector to be a base64 encoded value. along with examples on encoding and decoding
|
@patmmccann @adam-zimmerman I have addressed all your comments. Can you please review and approve the entire PR so we can move forward thanks. |
|
@hillslatt we're good to merge this PR |
Add Agentic Audiences Community Extension
This PR adds a community extension document for Agentic Audiences in OpenRTB. Agentic Audiences (formerly the User Context Protocol/UCP) is an IAB Tech Lab standard that defines how intelligent agents in advertising exchange vector embeddings representing consumer intent and ad response.
Summary
The extension specifies how embeddings are sent in bid requests. They are placed in
BidRequest.user.datausing the standardDataandSegmentobjects.Structure
Dataobject with aname(provider identifier) and asegmentarray.id,name, andext.Segment.ext:ver,vector,model,dimension, andtype.typearray indicates signal type: 1 = identity, 2 = contextual, 3 = reinforcement.Files Changed
extensions/community_extensions/agentic-audiences.md– full specification with attribute definitions, embedding type values, single and multiple provider examples, client-side storage notes, and implementation guidanceextensions/community_extensions/README.md– added Agentic Audiences entryReferences