Pixels and webhooks and are some of the foundational technologies that link the adtech world together. Pixels allow tracking systems to know who’s seeings ads and who’s moving along the funnel. Webhooks allow different tracking systems to sync up with one another so that everyone has the latest data to work with. At Pretio, a big part of our job is doing integrations with brands, apps, and networks, and it always depends on mutual understanding of the technologies involved. So, here’s our simple introduction to pixels and webhooks: what they are, why we need them, and how we set them up.

Every integration is different and this post can’t cover all the bases, but the purpose of this post is to help you think in terms of information flow. If you think in terms of this flow, then integrations will make a lot more sense and will be easier to set up.

Where Do You Fit?

Check out the infographic in this post. Where does Pretio fit into your business? If you have a brand to share with customers, you’re on the right. If you have an app to monetize, you’re on the left. All three players in this model need up-to-date data, and webhooks and pixels are how we achieve that.

Pixels

Tracking pixels aka. pixels allow cloud-based tracking systems to know what users are doing. Pixels are small messages sent from a user’s device to a server. They are commonly placed inside HTML-based ad units or landing pages in the form of a 1x1-pixel image — hence their name! But really, all you need to understand about pixels is that they report the occurrence of a particular action by a particular user. This could mean an impression, a conversion, a click, a Key Performance Indicator (KPI), or anything else you need to monitor and track. Chances are that most or all of your metrics about user activity start with pixels. In our infographic, you can find the pixels firing from the phone to the cloud services as the user progresses along the funnel.

But it’s not enough to just load a 1x1-pixel image on your landing page or ad-unit — that would tell the server that an event has occurred, but doesn’t say anything about the event or who performed it. For this reason, we always place more details in the URL of the pixel.

For example, say we received a pixel at this URL:

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=purchase

Here the imaginary advertiser “Best Shoe Company” is sending us a KPI pixel and also letting us know that the “type” of KPI was “purchase” — ie. the customer bought something. We can put as many other fields in the URL as we need.

Webhooks

Webhooks allow different ad-tech systems to sync data with each other and get the latest performance metrics to your dashboard. While pixels are device-to-server messages, webhooks are server-to-server messages. Check out the infographic, and notice the webhooks firing between the cloud services in the upper half of the image. Otherwise they are very similar to pixels: an HTTP request to a server, with data added to the URL.

Webhooks are sometimes called postbacks. We prefer not to use the term “postback” because it has other meanings in web development. To avoid ambiguity, we just call them webhooks.

A few common points of confusion

Terminology

Make sure you understand the terminology your partners are using, and be aware that in this fast evolving adtech space there are often multiple competing standards for what to call things. Don’t worry if you come to the table with different sets of tech jargon!

Who needs to send a pixel/webhook to who?

This depends on the integration and is one of the biggest sources of confusion we encounter. Sometimes tracking platforms will provide you with webhook URLs or ask you to enter URLs without a direct explanation of where they should go or where to get them from. This is particularly troublesome with conversion pixels and KPI pixels, because it’s a bit ambiguous where such events can take place, and depends on the individual integration. (As opposed to impression pixels, for example, which generally always take place in an ad-unit.)

We need to think about the flow of information in the adtech world. Check out the infographic on this post, and think about where your company fits into the picture. What pixels and postbacks will you be sending, based on the picture? What about receiving?

Here are some examples:

  • Impression Pixels
    • Fire from an ad unit to a tracking platform
  • Impression Webhooks
    • Fire from one tracking platform to another tracking platform after an impression takes place.
  • Conversion Pixels
    • Fire from a landing page to a tracking platform
    • Fire from a mobile app to a tracking platform
  • Conversion Webhooks
    • Fire from one tracking platform to another tracking platform after a conversion takes place
  • KPI Pixels
    • Fire from a brand’s website to a tracking platform
    • Fire from a mobile app to a tracking platform

Where does the URL come from?

The URL is the web address that webhooks and pixels fire to. If you use a tracking platform such as Cake, hitpath, or HasOffers, you can get the URLs from there. If your company has a custom system, then you’ll have your own set of URLs to use. Ultimately, the URLs are arbitrary — they just depend on the software you’re using.

Variables, macros, and templates…?

These terms refer to the part of the webhook that contains data specific to the individual event. There’s no universal standard on this terminology! In this post, I’ll call these dynamic values in URLs “variables”. If you learn to recognize URLs with variables in them, you’ll be more likely to get a working integration on the first try.

While pixels and webhooks are the connections that link adtech together, these variables are the data that they carry.

For example, let’s think about the the KPI pixel we used above:

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=purchase

It contains a variable called “type”, which in this case has a value “purchase”, but could have any value.

The original URL that we (Pretio) gave to Best Shoe Company probably looked liked this:

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=KPI_TYPE

Depending on their system, Best Shoe Company might enter this as any of the following:

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type={ type }

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=< type >

http://offers.pretio.in/advertisers/best_shoe_company/kpi.gif?type=#type#

Etc.

When the pixel or webhook fires your system will plug the right variable into the URl and the integration will work — if you got the formatting and the name of the variable right!

Conclusion

At the end of the day pixels and webhooks are the technology that allow advertisers and publishers to track performance in real time. We hope this post has helped you understand these tools, and the general flow of information in adtech today.

We’ve tried to provide all the basic concepts and common misunderstandings. Have we missed anything? What problems and confusions have you encountered while setting up pixels and webhooks?