How it works

Building and Interpreting a Model

Pontiac models, including User Defined Models, evaluate bid requests using scores assigned to individual attributes and combinations. For User Defined Models, these entries are supplied in an uploaded JSON or CSV file and may optionally include custom field weights.

The model acts as a lookup table. It does not calculate a prediction directly from the raw request. Instead, the classifier identifies the model entries that match each bid request, combines their scores, and produces a request-level score that the bidder uses to determine bidding behavior based on the line’s configured model settings.

This article explains how Pontiac interprets and applies model scores. For the supported fields, file formats, field-weight configuration, and structure required to create a custom model, see User Defined Models.

Building a Model File

A model file may contain three entry types:

• Individual attribute entries
• Two-variable combination entries
• Three-variable combination entries

You may mix all three entry types within the same JSON array. Their order in the file does not affect scoring, and a model does not need to contain every entry type.

[
  { "feature": "geo_zip", "value": "10025", "score": 0.95 },
  { "feature": "geo_zip", "value": "07302", "score": -0.60 },
  { "feature": "device_type", "value": "4", "score": 0.30 },
  { "feature": "publisher_name", "value": "iheartmedia", "score": 0.40 },
  { "feature": "publisher_name", "value": "lowvaluenet", "score": -0.85 },

  {
    "feature1": "geo_zip",
    "feature2": "device_type",
    "combination": "10025 × 4",
    "score": 0.90
  },

  {
    "feature1": "geo_zip",
    "feature2": "publisher_name",
    "feature3": "device_type",
    "combination": "10025 × iheartmedia × 4",
    "score": 0.85
  }
]

For combination entries, the values in combination must appear in the same order as the corresponding feature1, feature2, and feature3 fields and must be separated by ×.

For example:

"feature1": "geo_zip"
"feature2": "device_type"
"combination": "10025 × 4"

means:

geo_zip = 10025 AND device_type = 4

Recommended Model Structure

Individual attributes should form the foundation of the model. They provide the broadest coverage and are the entries most likely to match available bid requests.

Add two-variable combinations when the interaction provides information that is not already represented by the individual attributes. For example, a publisher-and-device combination is useful when that publisher performs materially differently on that device type than would be expected from the publisher and device scores independently.

Avoid adding combinations that merely repeat the same information as their component attributes. Because every matching entry participates in the combined score, an unnecessary combination may dilute stronger signals without improving the model.

Use three-variable combinations selectively. They are highly specific, match less frequently, and may be more likely to represent patterns that do not generalize beyond the source dataset.

A practical order for developing a model is:

1. Add the strongest individual attributes.
2. Add two-variable combinations that show a meaningful interaction.
3. Add three-variable combinations only when there is strong evidence that the specific interaction is reliable.

An existing Pontiac Analytics report may provide a useful starting point. The Downloads tab of a completed targeting report includes per-value and combination scores using the same feature vocabulary and −1-to-1 score scale. These scores can be reviewed, pruned, and adjusted before being used in a User Defined Model.

Pontiac Analytics models apply the same principle when selecting combinations. Every single-value entry that clears the evidence requirements is included, while two- and three-variable combinations are capped at 400 total entries, selected by absolute signal strength across both positive and negative directions.

The combination limit is deliberate. Because every matching entry participates in the combined score, a weak combination does not remain inert simply because its signal is small. When it matches, it takes a share of the average and can pull the result toward neutral.

Testing across 10 reports found that a 400-combination limit ranked inventory better than a 1,500-combination limit. In the same evaluation, including no combinations at all also performed better than including 1,500.

As a result, the combination entries available from a Pontiac Analytics report are intentionally pruned. A report used as the starting point for a User Defined Model does not represent every combination identified during analysis; it contains the strongest combinations retained for model scoring.

What Model Scores Mean

Model-entry scores are relative signals. They are not literal probabilities, predicted conversion rates, or guarantees of performance.

For example, a model score of 0.80 does not mean that a request has an 80% probability of converting. It means that the value represents a stronger positive signal for the model’s objective than a value scored 0.60.

Scores in the model file use a scale from −1 to 1:

Model Score	General Interpretation
0.8 to 1.0	Strong positive signal
0.3 to 0.7	Moderate positive signal
−0.3 to 0.3	Weak or inconclusive signal
−0.7 to −0.3	Moderate negative signal
−1.0 to −0.8	Strong negative signal

The most important considerations are the ordering of the scores and the distance between them.

Values near 1 and −1 should be reserved for the strongest and most reliable signals. If every entry is assigned a similarly high score, the model has little ability to distinguish between inventory opportunities and may behave more like an include list than an optimization model.

Weak or inconclusive entries are generally better omitted. A score of 0 is not ignored. It is treated as a matching entry and contributes to the average, pulling the final result toward the neutral midpoint.

What Is Inside a Pontiac Analytics Model

A User Defined Model contains the scores supplied in the uploaded model file. A model produced by Pontiac Analytics is assembled from multiple sources.

Entry Type	Score Source
Individual attribute	50% normalized SHAP + 50% empirical-Bayes signal from observed rates
Individual attribute with no SHAP available	Empirical-Bayes signal only
Two- and three-variable combinations	Empirical-Bayes signal only
Per-field weights	SHAP-derived

The 50/50 blend used for individual attributes is a measured choice rather than a default. Across temporal validation splits, it performed better than either pure SHAP or pure observed-rate scoring.

For this reason, the scores produced by Pontiac Analytics should be understood as attribution-informed evidence scores, not SHAP values.

This distinction is especially important for combinations, which contain no SHAP component. SHAP contributes to individual-attribute scoring where available and to the field-importance weights used when matching scores are combined, but it is not the sole source of the model’s scores.

Model Confidence

Each Pontiac Analytics report includes a model confidence rating of high, medium, low, or none. The rating is displayed at the top of the report’s executive summary and stored with the report.

Confidence considers three areas:

• The number of observed conversions or clicks relative to measured minimums
• The model’s cross-validated ranking ability
• The amount of training data supporting each field

The overall confidence rating reflects the weakest of these components because insufficient support in any one area can undermine the reliability of the model.

For practical use:

• Low — treat the model as directional. Do not scale spend based on the model alone.
• None — no bid model was produced.

ser Defined Models do not receive a confidence rating. Confidence represents a measurement of the data supporting an Analytics-generated model, and a hand-written model file does not contain that measured evidence.

How Bid Requests Are Evaluated

For each bid request, the classifier reviews the fields referenced by the model and attempts to match:

• Each individual value
• Each available two-variable combination
• Each available three-variable combination

Empty request fields are skipped.

For example, a request containing geo_zip, device_type, and publisher_name may generate seven possible lookups:

• Three individual values
• Three two-variable combinations
• One three-variable combination

Only entries that both exist in the model and fully match the request contribute to the request-level score.

An entry for a different value does not contribute. A combination entry contributes only when every feature and value in the combination matches the request.

When no model entry matches, the request receives a bidder score of exactly 0.5.

This is the neutral score. It does not mean there is a 50% probability of conversion. It means the model has no applicable positive or negative signal for that request.

How Matching Scores Are Combined

When multiple entries match, the classifier combines them into a weighted average.

For Analytics-generated models, weights are based on field importance, which reflects how strongly each field contributes to the modeled outcome based on the model’s training data. Weights are normalized so that the average field has a weight of 1.

Individual attribute entries use the weight assigned to that field.

For two- and three-variable combinations, the entry weight is the mean of the weights of its component fields. A combination does not receive additional weight simply because it contains more variables.

For example, if:

geo_zip weight = 1.2
device_type weight = 0.8

then:

geo_zip × device_type combination weight =
(1.2 + 0.8) ÷ 2 = 1.0

Conceptually:

Combined model score =
Sum of each matching score × its weight
÷
Sum of all matching weights

How field weights are determined depends on the model type.

Pontiac Analytics-generated models may include field-importance weights measured automatically from the model’s training data. When the model is built from fewer than 50 training rows per field, there is not enough data to apply field-importance weighting reliably and the model falls back to equal weighting. Models built before field-importance weighting was introduced also continue to score as they did previously.

User Defined Models use equal field weighting by default, with each field effectively weighted 1. Users may optionally supply custom field weights in the model file when there is a specific reason to give one field more influence than another.

User-supplied weights are normalized so that the average field weight is 1. Only the relative relationship between weights affects scoring.

For example:

site_domain weight = 3
hour weight = 1

has the same relative effect as:

site_domain weight = 30
hour weight = 10

For User Defined Models, fields without a custom weight use the default field weight of 1.

The combined score remains on the original −1-to-1 scale. It is then converted to the 0-to-1 bidder scale:

Bidder score = (Combined model score + 1) ÷ 2

Examples:

Combined Model Score	Bidder Score
−1.0	0.0
−0.4	0.3
−0.2	0.4
0.0	0.5
0.3	0.65
0.6	0.8
1.0	1.0

A bidder score above 0.5 represents a net-positive model result. A bidder score below 0.5 represents a net-negative result.

For instructions on supplying custom field weights in JSON or CSV, see User Defined Models.

How Multiple Signals Interact

A request’s score depends on the strength and direction of all matching entries.

More matches do not automatically produce a higher score. Because the classifier calculates an average, adding an entry that is weaker than the existing average can lower the final score even when that entry is positive.

For the following example, assume no custom field weights are supplied, so each matching entry contributes equally.

Consider a request matching:

• geo_zip = 10025: 0.95
• device_type = 4: 0.30
• 10025 × 4: 0.90

For this example, assume each matching entry contributes equally.

The combined model score is:

(0.95 + 0.30 + 0.90) ÷ 3 = 0.7167

The bidder score is:

(0.7167 + 1) ÷ 2 = 0.858

Adding a positive entry scored 0.40 could reduce this result because 0.40 is weaker than the existing combined score.

Positive and negative signals can also cancel one another. For example:

geo_zip score:       0.95
publisher score:    -0.85

Their combined model score is:

(0.95 − 0.85) ÷ 2 = 0.05

The bidder score is:

(0.05 + 1) ÷ 2 = 0.525

Although the request contains a strong positive signal, the strong negative signal nearly offsets it and produces a result close to neutral.

Custom field weights can change how strongly each matching signal affects this average. They do not change the underlying entry scores themselves.

Worked Example

Assume the model contains the following entries and that no custom field weights are supplied, so each matching entry contributes equally.

Entry	Model score
geo_zip = 10025	0.95
geo_zip = 07302	−0.60
device_type = 4	0.30
publisher_name = iheartmedia	0.40
publisher_name = lowvaluenet	−0.85
10025 × 4	0.90
10025 × iheartmedia × 4	0.85

The following bidder scores are produced:

Request	Matching Entries	Bidder Score
10025, device 4, iheartmedia	5	0.840
10025, device 4, unknown publisher	3	0.858
Unknown ZIP, device 4, unknown publisher	1	0.650
Unknown ZIP, device 2, unknown publisher	0	0.500
10025, device 2, lowvaluenet	2	0.525
07302, device 2, lowvaluenet	2	0.138

The second request scores slightly higher than the first, even though the first request matches more positive entries. This occurs because the additional matching signals for the first request are weaker than its stronger positive signals and lower the overall average.

If custom field weights were supplied, the same matching entries could produce a different combined score because fields with higher weights would contribute more heavily to the result.

Writing Model Values

Values must correspond to the format used in Pontiac impression logs.

Matching is case-insensitive and leading and trailing whitespace are removed. Other transformations should not be assumed.

Field	Group	How to write the value
geo_region	Geography	Lowercase, exactly as it appears in the logs.
geo_zip	Geography	Postal code as it appears in the logs. US ZIPs must keep their leading zero (‘04501’). Non-US formats are fine (‘1000-001’, ‘SW1A 1AA’).
publisher_name	Inventory	Lowercase, exactly as it appears in the logs.
site_domain	Inventory	Lowercase, exactly as it appears in the logs.
app_bundle	Inventory	Lowercase, exactly as it appears in the logs.
exchange	Inventory	Lowercase, exactly as it appears in the logs.
deal_id	Inventory	Lowercase, exactly as it appears in the logs.
content_channel	Content	Lowercase, exactly as it appears in the logs.
content_network	Content	Lowercase, exactly as it appears in the logs.
content_series	Content	Lowercase, exactly as it appears in the logs.
content_title	Content	Lowercase, exactly as it appears in the logs.
content_genre	Content	Lowercase, exactly as it appears in the logs.
content_livestream	Content	‘0’ or ‘1’.
device_type	Device	IAB code as a whole number — ‘3’, never ‘3.0’ and never ‘Connected TV’.
day	Time	Lowercase three-letter code (mon, tue, wed, thu, fri, sat, sun), in UTC.
hour	Time	Whole number 0-23, in the user’s LOCAL time.

Do not create entries for an empty string or for a placeholder value such as missing. When an attribute is absent, the bidder provides an empty field, and empty fields are skipped during matching.

Entries that cannot match a bid request are also removed automatically.

When a User Defined Model is uploaded, entries containing unreachable values, such as empty values or placeholders like missing, are dropped and the uploader reports how many entries were removed.

The Pontiac Analytics pipeline applies the same cleanup before the combination limit is applied.

As a result, an uploaded or generated model may contain fewer entries than the source data if unreachable entries were removed.

How Thresholds Affect Bidding

The model produces a bidder score between 0 and 1. In standard probability-based, or prob, output mode, two thresholds determine how that score affects bidding:

• Minimum threshold — scores at or below this value never bid.
• Maximum threshold — scores at or above this value always bid.
• Between the minimum and maximum — the request bids with probability equal to its bidder score.

In prob mode, bidding behavior is controlled by a minimum and maximum threshold. When a Single Value threshold is selected, the same value is used for both thresholds, producing a hard cutoff. When Spread is selected, separate minimum and maximum values define a probabilistic band.

Bidder Score	Outcome
At or below the minimum (0.30 by default)	Never bids
Between the minimum and maximum	Bids with probability equal to the bidder score
At or above the maximum (0.80 by default)	Always bids

The bidder score is used directly as the probability within the band. It is not rescaled based on the minimum and maximum.

For example, with the default 0.30 to 0.80 band:

• Score 0.29 → 0% bid probability
• Score 0.40 → 40% bid probability
• Score 0.50 → 50% bid probability
• Score 0.70 → 70% bid probability
• Score 0.81 → 100% bid probability

This means the thresholds define where probabilistic bidding begins and ends rather than converting the score range between them into a new 0%-to-100% scale.

The minimum and maximum thresholds are selected when the model is activated on a line. They are not stored within the model file, allowing the same model to be used with different bidding behavior on different lines.

Setting the minimum and maximum to the same value produces hard-cutoff behavior: scores at or below that value never bid, while scores above it always bid.

The equivalent point on the original −1-to-1 model scale can be calculated for either threshold as:

Equivalent model score = (2 × bidder threshold) − 1

For example, the default thresholds correspond to:

Bidder Threshold	Equivalent Model Score
Minimum: 0.30	-0.40
Maximum: 0.80	0.60

In classification, or cls, output mode, the configurable minimum and maximum thresholds do not apply. Classification uses a fixed 0.5 cutoff. A request is eligible only when its result is above 0.5.

Why the Neutral 0.5 Score Matters

A request that matches no model entry always receives the neutral bidder score of 0.5.

In prob mode, how that unmatched request behaves depends on where 0.5 falls relative to the minimum and maximum thresholds:

• Minimum at or above 0.5 — unmatched inventory never bids.
• Maximum at or below 0.5 — unmatched inventory always bids.
• 0.5between the minimum and maximum — unmatched inventory bids approximately 50% of the time.

With the default minimum of 0.30 and maximum of 0.80, 0.5 falls inside the probability band. An unmatched request therefore bids approximately half the time.

Where the thresholds sit relative to 0.5 can materially change how the model behaves.

A minimum of 0.5 or higher prevents neutral, unmatched inventory from bidding, making the model behave more like an allowlist of inventory with positive model signals.

A maximum of 0.5 or lower causes neutral, unmatched inventory to always bid, making the model behave more like a blocklist against negatively scored inventory.

When 0.5 falls inside the band, as it does by default, unmatched inventory remains available probabilistically while positive and negative model signals increase or decrease the likelihood of bidding.

Example Threshold Decisions

Assume the following requests receive these bidder scores:

Request Result	Bidder Score
Strong positive alignment	0.875
Moderate positive alignment	0.650
Positive and negative signals nearly cancel	0.525
No model entry matches	0.500
Moderate negative alignment	0.400
Strong negative alignment	0.138

With the default minimum of 0.30 and maximum of 0.80:

Bidder Score	Bidding Behavior
0.875	Always bids
0.650	Bids approximately 65% of the time
0.525	Bids approximately 52.5% of the time
0.500	Bids approximately 50% of the time
0.400	Bids approximately 40% of the time
0.138	Never bids

The minimum controls which lower-scoring requests are completely excluded. For example, increasing the minimum to 0.50 means requests scoring 0.500 or below never bid.

The maximum controls which higher-scoring requests are guaranteed to bid. For example, decreasing the maximum to 0.50 means requests scoring 0.500 or above always bid.

Requests that remain between the two thresholds continue to bid probabilistically according to their bidder score.

Score Distribution and Delivery

A model’s bidder scores may occupy only a narrow portion of the theoretical 0-to-1 range.

For example, a model may produce observed bidder scores only between 0.42 and 0.61.

With the default minimum of 0.30 and maximum of 0.80, every score in that observed range falls inside the probability band. Those requests therefore bid between approximately 42% and 61% of the time.

If the minimum is increased to 0.50, requests scoring at or below 0.50 no longer bid, while requests above 0.50 and below the maximum continue bidding probabilistically.

If the maximum is decreased to 0.50, requests scoring at or above 0.50 always bid, while scores below 0.50 but above the minimum continue bidding probabilistically.

If the minimum is set above the model’s entire observed score range, none of those scored requests bid. If the maximum is set below the entire observed range, all of those scored requests always bid.

Threshold selection should therefore account for the score distribution the model actually produces, not only the theoretical 0-to-1 scale.

Coverage and Signal Agreement

Two factors are especially important when evaluating how a model will affect bidding.

1. Coverage

Coverage describes how frequently the model contains an entry that matches available bid requests.

For example, a model containing only ZIP-code entries can strongly influence requests whose ZIP codes are represented in the model. Requests with ZIP codes not represented in the model receive the neutral bidder score of 0.5.

Other request fields do not dilute a matching ZIP score unless corresponding entries for those fields also exist in the model and match the request.

The limitation of a ZIP-only model is therefore the percentage of inventory covered by the listed ZIP codes, not the number of additional attributes present in each request.

Coverage is especially important because a request that matches nothing receives 0.5, meaning the model has no positive or negative signal for that request. Its bidding behavior then depends entirely on where 0.5 falls within the configured threshold band.

2. Signal Agreement

Matching entries that point in the same direction and have similar strength can produce a decisive positive or negative result.

Conflicting entries pull the combined score toward the neutral midpoint. Adding more entries does not necessarily widen the model’s score distribution, particularly when those entries are weak or contradictory.

A useful model should provide meaningful separation between preferred and discouraged inventory rather than simply maximizing the number of entries.

Selecting Initial Thresholds

Pontiac Analytics models are evaluated against a sample of real bid requests during the model-building process. This makes it possible to review the distribution of bidder scores across observed marketplace inventory and understand how different minimum and maximum thresholds may affect bidding behavior.

A manually or externally created User Defined Model may not initially have an observed score distribution. It should therefore be evaluated against sample bid requests whenever possible before being used for live bidding.

When activating a new model:

1. Review the range and distribution of request-level bidder scores.
2. Identify the percentage of requests receiving the neutral score of 0.5.
3. Determine how much inventory falls at or below the minimum and therefore will never bid.
4. Determine how much inventory falls at or above the maximum and therefore will always bid.
5. Review the inventory between the thresholds, where bid probability equals the bidder score.
6. Pay particular attention to where 0.5 falls within the band because this determines how unmatched inventory behaves.
7. Adjust the minimum and maximum while monitoring delivery and performance.

The thresholds should not be selected based only on how strict the values appear. They should reflect the model’s actual score distribution, inventory coverage, desired bidding behavior, campaign delivery requirements, and optimization objective.