Anti-Targeting Solution | NVIDIA Structured Data and Graph Models

Solution Background and Business Value

Anti-targeting during digital advertisement campaigns helps businesses identify customers least likely to purchase a promoted product, so they can reallocate resources away from users unlikely to convert. This strategy matters most for campaigns with limited budgets or short timelines, where wasting impressions on uninterested users reduces efficiency.

These problems can be approached from different angles, each requiring distinct predictive models. Kumo supports two interpretations of anti-targeting: one using a static prediction and one using a temporal prediction. The key difference is how the training tables are constructed, so the right choice depends on your use case.

To train an anti-targeting model, you need a structured set of tables capturing campaign data, user data, and transaction history. More tables and richer data improve model accuracy, but the schemas below represent the minimum required.

Example: Anti-targeting in flight throughout the campaign

In-flight anti-targeting requires a model trained for temporal predictions. When constructing a training table for temporal predictions, the model samples several past moments for each user. For example, to predict whether a user will act in the next 30 days, the model samples 30-day intervals in the past to build training data. This captures behavior over time, which is useful for anti-targeting during active campaigns.

This example uses three tables: campaign data, user data, and session data. Each user is associated with one campaign, and each user has multiple sessions that record purchase activity.

Core Tables:

Campaign Data:
- Stores all data about each campaign
- Key attributes:
  - campaign_id: unique campaign identifier
  - start_date: start time of campaign
  - Optional: daily budget, campaign type, campaign name
User Data:
- Stores all data about each user
- Key Attributes:
  - user_id: unique user identifier
  - acquired_through_campaign: boolean that represents how this user was acquired
  - campaign_id: which campaign this user is associated with
  - Optional: age, gender, income, signup date, income range, and so on
Session Data:
- Stores all data about every session a user has
- Key Attributes:
  - session_id: unique session identifier
  - user_id: the user this session belonged to
  - claim_reconciled: the user made a purchase
  - Optional: duration, engagement score, sale type, claim site, and so on

Additional Tables (Optional):

For improved prediction, consider including:

Payload Table: Data about each transaction within each session (for example, interaction time or margin)
Ad Group Data Table: Data about the targeted audience of each campaign

Entity Relationship Diagram (ERD)

Sub Graph:

Kumo creates a subgraph of each graph centered on the entity being predicted. Since this model predicts whether each user will purchase a product, the subgraph is centered on each user. Here is an example subgraph for the schema above:

By default, model plans only consider nodes up to two hops from the root node. However, since the subgraph is centered on each user, two hops would only include the user, their campaign, and other campaign users, omitting session data for those other users and losing useful information. To address this, manually add a third hop in the model plan before training.

Predictive Query:

Anti-targeting identifies users least likely to purchase a product promoted by a specific campaign. One decision is whether to filter out users who have already purchased the product. For high-price or non-perishable items, a user is unlikely to buy the same item twice during one campaign, so it may be valuable to consider only users who have never purchased the item before.

PREDICT COUNT(session_data.* WHERE session_data.claim_reconciled = 'False', 0, N, days) > 0
FOR EACH user_features.user_id
WHERE user_features.campaign_id = K 
AND COUNT(session_data.* WHERE session_data.claim_reconciled = 'True', -inf, 0, days) = 0

At prediction time, this model predicts the likelihood that a user associated with campaign K will not purchase the promoted item in the next N days, given that the user has not purchased it before.

Example: Anti-targeting at the beginning of an advertisement campaign

Anti-targeting at the start of a campaign requires a model trained for static predictions. Unlike temporal predictions, static predictions consider features at a single point in time. Because of this, each entity must correspond to exactly one label; the same entity cannot have multiple entries in a training table. One workaround is to add duplicate entities with different timestamp properties.

Static predictions require pre-generated label tables or columns that represent the target outcome. This gives you fine-grained control over the training period. For example, instead of iteratively sampling past intervals like temporal predictions, you can specify a fixed window, such as a month or a season.

This example uses four tables: user data, orders, products, and labels. The schema represents data for a single campaign. Each user places several orders, each with one product attributed to it.

User Data:
- Stores static data for each user
- Key Attributes:
  - user_id: unique user identifier
  - Optional: age, gender, income, signup date, income range, and so on
Orders Data:
- Stores all transactional data about each purchase made
- Key Attributes:
  - order_id: unique order identifier
  - user_id: the user that made the order
  - product_id: the product that was purchased
  - time_created: when the order was placed
  - promoted_flag: whether or not the product was promoted by the campaign
Product Data:
- Stores metadata about each product
- Key Attributes:
  - product_id: unique product identifier
  - Optional: product name, brand, size, category, price
Label Table:
- Stores binary labels for supervised learning tasks
- Key Attributes:
  - label_id: unique label identifier
  - user_id: the user this label is associated with
  - time: when the label applies
  - target (1/0): binary outcome for prediction (for example, purchase or not)

Entity Relationship Diagram (ERD)

Predictive Query:

For static predictions, the challenge is not writing the query but pre-generating the labels. Labels represent what you want to predict: for each user, a 1 if they bought the promoted product within the desired timeframe, or 0 if they did not. With those labels in place, the predictive query is:

PREDICT LABELS.TARGET = 0
FOR EACH LABELS.ID

Since labels and users have a one-to-one relationship, this short query is all that is needed.