As an Adobe Audi­ence­M­an­ager (AAM) user, you are already famil­iar with the “trait,” which is the most gran­u­lar data point in the plat­form. Once you are com­fort­able with Trait Builder basics, you can per­form a few new tricks to take your data col­lec­tion to medal-worthy levels.

HTTP Head­ers

Real-time data col­lec­tion hap­pens through event calls (HTTP requests), which con­tain a mul­ti­tude of detailed page– and visit-level infor­ma­tion in the form of query string key-value pairs. Most of your traits are built off these query string para­me­ters (props, evars, events, etc.), but on every event call there is another chunk of data con­tained in the HTTP request header. You can use the header field to build traits as well.

One inter­est­ing way to seg­ment users based on their HTTP request header infor­ma­tion is to use the Accept-Language field. On any request from a browser, this field tells the web­server which lan­guage the vis­i­tor prefers. In return, the web­server responds with the web­page text in the cor­rect lan­guage. When build­ing traits with HTTP request head­ers, the name of the header is always the key, but you must start it with “h_” — for exam­ple, “h_accept-language.” This pre­fix tells AAM to inspect the HTTP header in the request.

As an exam­ple, try cre­at­ing a trait named “Span­ish Speak­ers.” Use the logic h_accept-language startswith ‘es’ to put folks into this trait when their first lan­guage pref­er­ence is Span­ish (“es” is for “Espanol”).

image 1 spanish

Build­ing out addi­tional rules requires some eas­ily obtained knowl­edge of HTTP head­ers and their val­ues (fol­low the link for more infor­ma­tion).  A cou­ple of other com­mon request head­ers are h_referer (to seg­ment users based on all or part of the URL they visit) and h_user-agent (to seg­ment users based on their browser/device).

Note: h_referer can eas­ily be con­fused with c_referrer. The lat­ter is an Adobe Ana­lyt­ics vari­able that sets the refer­ring (pre­vi­ous) page URL, where h_referer passes the actual page the vis­i­tor is on. Note again that the h_ pre­fix tells AAM to inspect the header, while the c_ pre­fix tells AAM to inspect the query string.

Test HTTP Header

When build­ing traits using HTTP header infor­ma­tion, some­times it is help­ful to test your logic. Once you have your logic setup, open Chrome and nav­i­gate to your site. Choose one of the “demdex​.net” event calls in Chrome’s devel­oper tools (net­work tab) and select “head­ers.” Next, select and copy the entire block under “request head­ers.” You can paste this straight into the “Test HTTP Head­ers” sec­tion of Trait Builder. If your logic matches, you’ll get a pop-up telling you so.

image 2 spanish

Reg­u­lar Expressions

Some­times, when a sim­ple “equals,” “greater than,” or “con­tains,” won’t do, match­es­regex can save the day. Let’s say you are a large retailer, and you have a vari­able that is pass­ing in sev­eral val­ues delim­ited by a pipe, like so:

c_evar21=electronics|tablet|0007009

Let’s assume that “elec­tron­ics” is the page/product cat­e­gory, “tablet” is the sub-category, and “7009” is the prod­uct num­ber (SKU) of a spe­cific tablet model. Let’s also assume that all tablets are in the “7000” range, and you’d like to cre­ate a trait con­sist­ing of vis­i­tors brows­ing any/all tablets. You can cre­ate the trait with the fol­low­ing logic:

Tablet Vis­i­tor Trait: c_evar21 match­es­regex .*0007[0–9][0–9][0–9]$

image 3 regex

This will match on a string that con­tains “0007” (and any­thing before it, because “.” is any char­ac­ter and “*” is “any num­ber of times”), fol­lowed by exactly three dig­its, each with a range from 0–9, and noth­ing after it (des­ig­nated by the “$”). This assumes that the SKU is always the last value in evar21, which will match any SKUs rang­ing from 0007000 to 0007999.

There are many read­ily avail­able resources if you’d like to learn more about reg­u­lar expressions.

Test Event URL

When you have advanced trait rules such as the one above, it can be help­ful to test your logic. You can do so in the Trait Builder UI under “Test Event URL.” Sim­ply place the HTTP call you’d like to test against your trait logic (or make one up) and hit “test.” Audi­ence­M­an­ager will tell you whether or not the event call would put a user into that trait.

image 4 regex

Geo Data Traits

Although we gen­er­ally rec­om­mend tar­get­ing vis­i­tor geos in the tar­get­ing plat­form itself, AAM also lets you seg­ment and ana­lyze users based on their loca­tion. You can choose from the fol­low­ing lev­els of detail:

  • Coun­try (exam­ple: d_country = usa)
  • Region (exam­ple: d_state = il)
  • City (exam­ple: d_city = chicago)
  • Metro (exam­ple: d_metro = 602)
  • Lat­i­tude (exam­ple: d_latitude > 41 AND d_latitude < 43)
  • Lon­gi­tude (exam­ple: d_longitude < −87 AND d_longitude > −88)

image 5 geo

If you’d like to setup geo traits or need help with any of the con­cepts explained above, please con­tact your Audi­ence­M­an­ager Consultant.

0 comments