trackers

What the Snap Pixel Sends From a Website, Hashed Email Field Included

Snapchat’s pixel loads scevent.min.js from sc-static.net and posts its events to tr.snapchat.com, mostly /p. It’s common on shops that advertise to younger buyers, and like the other ad pixels it counts conversions and feeds audiences.

The request is a short form post. Four or five fields cover the event, the page, and, when it’s set up, the visitor’s hashed email.

A Snap Pixel request decoded by PXTA: the pixel ID, the event name PAGE_VIEW, the page address, and a hashed email address in u_hem, with the page address and the hash highlighted.

The Fields That Matter

  • pid is the pixel ID and ev the event, such as PAGE_VIEW, ADD_CART or PURCHASE.
  • pl is the page address and rf the referring page.
  • u_hem is a hashed email and u_hpn a hashed phone number.

Where It Usually Goes Wrong

A hashed email on every page. Once a site passes the visitor’s email to the pixel, for example after login, u_hem can go out with every page view, not only with purchases. PXTA counts each page where it appears.

The page address. As with every pixel here, pl sends whatever the address holds, query string included.

Consent. The Snap Pixel has no built-in link to cookie banners. It waits only if the site or tag manager makes it wait.

What PXTA Can’t See

Snap’s Conversions API sends events from a site’s server, which a browser audit can’t observe. The same caveat holds for every ad network here: the browser report is half the picture when a site uses both.