Attributions

Overview

As a part of your integration, Kard has solutions to power user attribution data collection. User attribution data points (metrics like impressions and views) are important because they help shed insight on how your users are engaging with parts of your rewards program. Attribution metrics are becoming requirements amongst merchants as Kard continues to partner with top-of-wallet everyday spend brands. In order to unlock these offers and drive stronger user engagement, providing user attribution data will be vital.

Kard has two options you can use to enable real-time user attribution data tracking. Please reach out to the Kard team if you have any questions about which solution is the best for you.

  1. Event Tracking via Images URLs. If you fetch or receive data from our APIs, attribution tracking tokens are automatically included with the assets we provide. These tokens are either embedded in the images associated with the data (i.e. logo and banner image images) or provided as a standalone link, called attributionUrl, which is a blank pixel you can overlay on your screen.
  2. Event Tracking via Attribution API Endpoint. If you already track attribution events like user impressions and views on your app and prefer this method, you can directly send us these events in real-time via endpoint. Learn more about our Attribution API Endpoint here.

Note: It is important to only send attribution data via one of these methods, not both.

The solution collects two events: IMPRESSIONS and VIEWS. These events are defined as the following:

  1. Impressions: Anytime a resource is loaded into your app experience for a user.
    1. An example here is when a user navigates to their rewards experience on your UX and views offers. An impression for a specific user means that an offer was loaded onto the screen, but does not guarantee that the user saw the specific offer. See below for a visual representation of these impressions events:
    2. Another example here is when a notification provided by Kard is displayed as a push notification on a user’s phone. An impression for a specific user means that the notification was loaded onto the screen, but does not guarantee that the user saw the specific message.
    list of rewards in app
  2. Views: Anytime a user performs an action (like a click) to view a resource in your app experience.
    1. An example here is when a user is shown a list of offers, and they click into a specific offer to view more details. This event is valuable because it indicates intention from a user towards a specific offer.
    2. Another example here is when a user clicks on a push notification, and is brought to the relevant screen in your app. This event is valuable because it indicates intention from a user towards a specific notification. See below for a visual representation this view event:
    in app pending reward notification

Both solutions also optionally capture a medium field, for issuers to be able to indicate where in their experience the event is happening. We highly recommend providing this field for more granular analyses. The following mediums are supported:

  1. Browse: This is the most common medium, and is defined as when a user is in the rewards section of your UX and is browsing through a list of offers.
  2. Map: Some issuers support a map view as a part of their UX to showcase offers to users nearby. This medium should be passed for impressions and views that occur within a map interface.
  3. Search: Some issuers allow users to search for offers as a part of their UX. This medium should be passed for impressions and views that occur within a search interface.
  4. Push: This medium should be passed for impressions of views that are associated with a push notification from an issuer’s app.

Event Tracking via Images

Kard’s API endpoints and webhook payloads may include image URLs or attribution URLs, with a token query parameter attached

1{
2  ...
3  "attributionUrl": "<https://attribution.getkard.com/public/logos/transparent.png?token=valid.signed.jwt>",
4  "imgUrl": "<https://attribution.getkard.com/image.jpg?token=valid.signed.jwt>",
5  "bannerImgUrl": "<https://attribution.getkard.com/banner.jpg?token=valid.signed.jwt>"
6  ...
7}

When you load this image in your app or website, you would simply append the eventCode so Kard can automatically connect the image with an IMPRESSION or VIEW event, and the medium so Kard can connect the event to whether it happened within BROWSE, MAP, SEARCH or PUSH mediums. eventCode is a required query parameter for event tracking via images.

1<img src="<https://attribution.getkard.com/image.jpg?token=valid.signed.jwt&eventCode=IMPRESSION|VIEW&medium=SEARCH|MAP|BROWSE|PUSH/>" />

If no medium is specified, Kard will attempt to determine the medium for this image view. By default, we will consider the medium to be BROWSE. We highly recommend that you include a medium query parameter string to ensure the most robust data collection.

Example Usage:

If you load a list of offers where the user is browsing their rewards experience, you would want to append an IMPRESSION eventCode for all offers that were loaded onto the screen, specifying BROWSE as the medium to the image URL.

If offer images are loaded on a map view to showcase nearby offers to users, you would want to append an IMPRESSION eventCode for all offers that were loaded onto the screen, specifying MAP as the medium to the image URL.

If a user searches for an offer and then clicks into it within your UX, you would want to append a VIEW eventCode and a SEARCH medium to the image URL.

If a user clicks on an earned reward notification, you would want to append a VIEW eventCode and a PUSH medium to the attribution URL.

Note: As part of this implementation, please do not cache any of these image URLs. We have already incorporated caching as part of our infrastructure at the CDN level, so any additional caching on your side is unnecessary and may impact our capture of real time data. This is a critical part of us being able to confirm that this attribution data is as accurate as possible!

Built with