Help on how to set the correct key_piece on Register-Trigger

[dbrito]

Hello everyone, everything good ?

Guys, firstly I apologize if the question is silly, but I was trying to validate my flow of recording conversions and I came across something that I'm having trouble understanding, following the example of attribution-reporting I saw that the information regarding the conversion step (type purchase = 2) was passed on as the hexadecimal 0x400, I understand that part of this hexadecimal value is made up of the 9 bits necessary to support the number of possible values from the previous step (511 | 0x1FF | 111111111), but I was unable to understand how the value "2" (0x2 in hexadecimal) from this step added to the 511 (0x1FF) possibilities from the previous step became 0x400 passed on in the example (print).

I ask this because I'm trying to integrate attribution-reporting into a real placement that we're going to do through GoogleAdManager, and in this test we're going to have to pass on larger values in the creative (Register-Source) and conversion (Register-Trigger) stages. Below are some examples

In the creative stage (Register-Source) I would have to pass on the CreativeId 138479866909 which in hexadecimal would be 0x203e0b141d In the conversion step (Register-Trigger) I would have to pass on the ConversionId 985 which in hexadecimal 0x3d9, but in this step I need to compensate for the space needed to support the value from the previous step, this is the part that I have difficulty understanding (T.T). Could you help me understand how this process would be possible ?

Thank you very much for your help

Best Regards,

[linnan-github]

Hi @dbrito, the final aggregation key in the aggregatable report is the bitwise OR of the source-side key piece and the trigger-side key piece. In the example, there may be 511 possible campaigns on the source registrations, therefore the source-side key piece takes up 9 bits to identify those campaigns. On the trigger side, the conversion type is 2. In order to identify the conversion type from the final aggregation key, the trigger-side key piece space should be disjoint from that of the source-side key piece, and that's why the offset is applied (2 << 9 = 0b10 << 9 = 0x400) so as to identify both source and trigger side information from the final aggregation key. Note that 0x400 only encodes the trigger-side data. In final aggregation key, the lowest 9 bits represents source-side information, and the higher ones represents trigger-side information. If the source-side key piece is 0x159 as in the example, the final aggregation key would be 0x159 | 0x400 = 0x559.

In your use case, you would need to allocate a number of bits sufficient to represent all possible CreativeIds on source side, e.g. 38 bits in your example, and apply offset for the ConversionId on trigger side, e.g. 0x3d9 << 38. Hope that helps!

[dbrito]

Hi @linnan-github,

Firstly thanks for the help

@linnan-github sorry, but would you be able to write in more steps how the value "2" becomes "0x400"? Sorry, I still don't understand completely

Thinking about a function I understood that I would have the variables below

//How to find 0x400 ? 

A) 2 = 0b10 = 0x2 (Purchase type)
B) 511 = 0b111111111 = 0x1ff (Total possibilities from the previous step)
C) 345 = 0b101011001 = 0x159 (Campaign)

Target Result: 1024 = 0x400 = 0b10000000000
Final AggregationKey: 0x400 ^0x159 = 0x559

*the part where I will have to cut the aggregation key according to the space occupied by each piece of information to get the information I kind of understand (I hope LOL)

*I apologize for the English, it's not my native language, I'll improve the math part

Thanks again

[linnan-github]

Hi @dbrito,

Here's how we get 0x400.

In order to account for all possible 511 campaigns, we need 9 bits (2^9 - 1 = 511), therefore the lowest 9 bits are reserved for the campaign information.

For the conversion type, it is 2 = 0b10. Since the lowest 9 bits are reserved and not used for conversion type, we left shift 0b10 by 9 bits, 0b10 << 9 = 0b100 0000 0000 = 0x400.

Please feel free to comment if it's still not clear.

[dbrito]

HI @linnan-github !

I think I finally understand !!!!! "2" becomes 0x400 when I concatenate its binary value (0b10) with the 9bits padding needed (000000000) to store the information from the previous step

//2 in binary + 9bits padding (0 nine times)
0b10 + 0b000000000 = 0b10000000000
0b10000000000 = 0x400

Thank you só much for your help