Keys following this structure would be 13-bit long (5 + 1 + 3 + 4). With this, the key structure map for these keys would look as follows: KEY STRUCTURE MAP Product category Bits 8 to 12 (12 ← 8) 5 bits 32 values Meas. goal Bit 7 1 bit 2 values Geo ID Bits 4 to 6 (6 ← 4) 3 bits 8 values Campaign ID Bits 0 to 3 (3 ← 0) 4 bits (16 values) 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 Bit # 12 11 10 9 8 7 6 5 4 3 2 1 0 The order of the dimensions within the key is up to you. To illustrate how dimensions make up a key structure, we'll be using a binary representation, which is why the Campaign ID (first bits) is the rightmost one, and the product category (last bits) is the leftmost one. Within each dimension, the most significant bit—the one that carries the greatest numerical value—is the leftmost bit. The least significant bit—the one that carries the smallest numerical value—is the rightmost bit. Let's see how you would use a key structure map to decode a key. Let's take 0b1100100111100 as an arbitrary example key, and let's assume you have a way to know that this key follows the key structure map above. According to the key structure map, this key would decode into: 11001 0 011 1100 Namely: Product category = Bits 8-12 = 0b11001 (binary) = 25 (decimal) ⇒ Product category = 25 Measurement goal type = Bit 7 = 0b0 (binary) ⇒ Measurement goal type = Purchase count (if as per your dimension map, 0 means "purchase count" and 1 means "purchase value".) Geo ID = Bits 4-6 = 0b011 (binary) ⇒ Geo ID = Europe (as per the dimension map above)) Campaign ID = Bits 0-3 = 0b1100 (binary) = 12 (decimal) ⇒ Campaign ID = 12 So the key 0b1100100111100 represents the number of purchases of Product category 25, for the Campaign ID 12 launched in Europe. Encoding dimensions into keys, approach 2: hash function With this technique, you rely on a hashing function to dynamically generate keys in a consistent and reliable way. There's no need to create or maintain key structure maps. This works as follows: Select a hashing algorithm. At ad-serving time, generate a string that includes all the dimensions you want to track, and their values. To generate the source-side key piece, hash this string and consider adding a 64-bit suffix of zeros (to align it with the trigger-side key piece and make XOR easier to reason about). Source-side key piece = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…> Note that COUNT encodes the same thing as measurementGoalType=0 in the key structure map approach. COUNT is a bit leaner and more explicit. At conversion time, generate a string that includes all the dimensions you want to track, and their values. To generate a trigger-side key piece, hash this string and add a 64-bit prefix of zeros: Trigger-side key piece = <64-bit 00000000…><64-bit hex hash("productCategory=25")> The browser XORs these key pieces to generate a key. 128-bit aggregation key = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash> Later, when you're ready to request a summary report for this key, generate it on the fly: Based on the dimensions you're interested in, generate a source-side and trigger-side key piece as you did earlier. Source-side key piece = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…> Trigger-side key piece =<64-bit 00000000…><64-bit hex hash("productCategory=25")> trigger-side key piece = toHex(hash("productCategory=25")) Just like the browser, XOR these key pieces to generate the same key the browser has generated earlier. 128-bit aggregation key = <64-bit source-side key piece hash><64-bit source-side key piece hash> A few practical tips if you're using this hash-based approach: Ensure you're always using the same ordering of the dimensions. This ensures that your hashes can be reliably regenerated. ("COUNT, CampaignID=12, GeoID=7" will not generate the same hash as "COUNT, GeoID=7, CampaignID=12"). One straightforward way to achieve this is to sort dimensions alphanumerically. This is what we'll be doing in the example, except for the fact that we'll always make COUNT or VALUE the first item in the dimension—this is a choice for readability, as COUNT or VALUE encodes information that's slightly different conceptually than all other dimensions.