FAQs (Pixels)

Why aren't any fires of my conversion pixels from my website form tests being recorded as "messaged" or "conversions" by the DSP?

For the fire to be recorded as "messaged" and count as a conversion, the Zeta DSP requires the entire flow from encountering a live ad impression through to visiting your conversion pixel to occur.

Why am I not seeing my pixels populate in the Report Builder?

If you are at viewing advertiser-level pixels, this is likely due to your pixels not having been placed. The pixels will only populate in Report Builder if they are firing, so double-check website placement.

If you are at the campaign-level pixels, make sure that you have assigned the pixels to the campaign on the Goals and Tracking tab of the Campaign Builder. If the pixels are not assigned to the campaign, they will only be viewable at the advertiser-level.

What is expected behavior when changing the pixel type on a pixel that is assigned to a campaign?

• When a conversion type pixel assigned to a campaign is changed to either landing or tracking type, conversions recorded in the past 60 days for that pixel will be zeroed out on the campaign.

• When a landing type pixel assigned to a campaign is changed to conversion type, attributed (messaged) fires in the past 60 days will be counted as conversions on the campaign.

• When a conversion type pixel assigned to a campaign is unassigned, conversions recorded up until the time it was unassigned will remain on the campaign

[JavaScript] How do we optimize a campaign using JavaScript tags?

The Zeta tag informs our system that an event occurred. Each tag we create is given a specific meaning in our platform. For example, we would typically define a tag to indicate that a user has reached the 'thank-you' page of your site.

Our tag also assigns a random/anonymous ID to the browser/device, and stores it in a cookie. The random ID enables us to link media impressions, site landings, and conversions for a browser/device over time.

[JavaScript] How does the JavaScript tag work technically?

The JavaScript tag is placed on the client pages and executes when a user loads the page. The tag constructs a simple iFrame that loads from the Zeta servers.
Each tag has a unique ID embedded in the request in the which indicates its purpose. For example, Tag ID 99999999 might mean that a conversion occurred.

[JavaScript] Will the Zeta tag impact my site's page load time?

The Zeta tag will not impact your site's page load time. Here is why:

• The Zeta JavaScript itself has loaded asynchronously so that the browser can continue loading/rending other assets in parallel while the iFrame is being constructed.

• We host the JavaScript on a top-tier CDN so that it is highly available and physically near the end-user to minimize load time/latency.

• Any partner cookie matching activity (described in more detail below) is done asynchronously (in parallel) as well. This means that if a cookie matching partner happens to be temporarily slow, then it wouldn't impact the other partners from completing the match process.

• We defer any partner matching until after the core page is done loading (after the window.onload event which is fired by the browser) to ensure that the end-user experience is prioritized over the marketing data.

[JavaScript] What are the other requests I see loading immediately after the Zeta tag?

The additional requests are called cookie match requests. Zeta bids across numerous exchanges to bring the best available ad inventory for our clients. Each exchange partner creates its own anonymous identifier/cookie for a given device/browser. For example,

Because each exchange refers to the same browser/device with a different random number, we need to know that Exchange A's 4567 is the same as Zeta's 1234 in order to have the appropriate information to calculate the optimal bid for an impression. The process of exchanging anonymous/random IDs is called cookie matching. Each time a Zeta tag loads, we match with exchange partners so that we will have the greatest chance of later recognizing a user and buying optimally on the client's behalf.

[JavaScript] What is Cookie Matching?

The process of exchanging anonymous/random user IDs with publishers and exchange partners is called cookie matching.

Each time a Zeta tag loads, we match with exchange partners so that we will have the greatest chance of later recognizing a user and buying optimally on the client's behalf. The better our cookie match rate, the better our ability to track individual users.

[JavaScript] What are your match partners able to see about my site?

Zeta loads match partner requests in an iFrame. One of the benefits of this approach is that partners can't access the parent page (your site) directly.

For example, built-in browser security ensures they can't access your site's JavaScript variables or page content. Match partners will be able to see details of our iFrame request such as the Tag ID and other headers and parameters (query strings).

[JavaScript] What data does the Zeta tag collect?

Zeta collects anonymous information in order to inform our bidding on our clients' behalf, including:

• Zeta anonymous/random user ID

• The Tag ID, which has a special meaning in our system (e.g., a conversion)

• Data from the request headers (e.g., URL of the current page)

• Optionally, the client can pass extra data such as order ID, order total, and products purchased to help further optimize the campaign.

[Pixel Piggybacking] Why Do We Piggyback?

In order to buy inventory efficiently (and programmatically), Zeta utilizes pixels from our exchange partners to match their user IDs with our internal user IDs. With this cookie matching strategy, we can have more insight to the user's actions and determine which user is more likely to convert. This is a standard programmatic practice and an effective strategy that we have always had in place. With that being said, we do have the ability to turn off these piggybacked pixels. However, the disabling of cookie matching would negatively impact campaign performance.

[Pixel Piggybacking] How Many Pixels Do You Piggyback?

We determine which pixels need to fire based on whether the user's IDs have already been matched or not. Therefore, our pixel might fire with 4 piggybacks one time or 10 the next depending on the user's cookies. If an image pixel were placed, we would only fire 4 to 5 at a time max regardless of the user's cookies. If a JavaScript pixel is placed, then it is possible that all 23 could fire if no cookies have previously been matched.

[Pixel Piggybacking] Will This Slow The Page Load?

Version 9+ pixels load asynchronously which means the page will load as the pixels are loading and in some cases, the page will have loaded before we have completely loaded the piggybacked pixels. Older pixels versions that we have supplied in the past are synchronous pixels, this means a pixel must be completely loaded before the next pixel in the chain can start to load. This can cause page load latencies, which many clients are sensitive to.

[Pixel Piggybacking] How Does Piggy Backing Relate to Cookie Matching?

In order for us to cookie match with our exchanges, we have to piggyback their pixels on to ours so that the exchange pixels fire exactly at the same time that our pixel fires. This way we can match the exact unique ID from our database with the exchange's unique ID that they have on that particular user

[Pixel Piggybacking] What Pixels Do We Piggyback?

In order to buy inventory efficiently (and programmatically), Zeta utilizes pixels from our exchange partners to match their user IDs with our internal user IDs. With this cookie matching strategy, we can have more insight to the user's actions and determine which user is more likely to convert. This is a standard programmatic practice and an effective strategy that we have always had in place. With that being said, we do have the ability to turn off these piggybacked pixels. However, the disabling of cookie matching would negatively impact campaign performance.

[Pixel Piggybacking] Can We Disable Piggybacking?

Yes, but this is our very last resort as it most likely will hurt performance. If your client requests this please reach out to Ops Management.

[Sharing Pixels] Can I use pixels from another Advertiser or Account?

Yes, pixels can be shared from one Company to another Company via the pixel settings. Open the Pixel (as described above), and then click Share with Accounts, and select the account.

It is recommended that pixels are not shared with the same Advertiser in which they were created. Doing so will create duplicates of the pixel for this Advertiser in the pixels list.

[Sharing Pixels] Can I use shared pixels on multiple Campaigns?

Yes, you may assign shared pixels to multiple campaigns.

[Sharing Pixels] Why would I re-purpose pixels instead of creating new?

Pixels collect a large amount of data and learnings that can be beneficial for our models. If the pixels are already placed on a page and have been firing for some time, it would be ideal to leave these pixels on the page and utilize the learnings rather than starting fresh. Additionally, getting pixels placed and firing properly can require significant lead time.

[Sharing Pixels] I shared pixels into a new company, but I don't see them in Analyze Pixels in the new advertiser

Pixel fire data can only be found under Analyze Pixels in the original advertiser where the pixel was created.

[Sharing Pixels] I am trying to select the shared pixels in the Forecaster and I don't see them

You will need to use the Forecaster tool under the shared pixel's original advertiser to pull avails.

[Cookie Matching] What Is Cookie Matching?

Cookie Matching is a way in which buyers such as Zeta and Exchanges such as AdX and AppNexus exchange their user identifiers so that user identifiers from these different sources can be mapped and used to buy inventory more efficiently and to gain more insight into user actions. This enables us to better determine which users are more likely to convert.