Kaliper Documentation
Restricting traffic
Restrictions let each entity block specific traffic sources or reject pings that fail data quality checks. All restriction settings are in the Cap and restrict block in each entity's Relay settings tab.
Restrict by source
Source restrictions let you block pings based on where they come from — which publisher, which buyer, or which Sub-ID they carry. Each entity type can restrict a different set of sources:
Entity | Can restrict |
|---|---|
Publisher | Buyers, Targets, Sub-IDs |
Buyer | Publishers, Sub-IDs |
Target | Publishers, Sub-IDs |
Campaign | Sub-IDs only |
Restricting buyers and targets (Publisher only)
A publisher can block specific buyers or targets from receiving its traffic. Any ping originating from that publisher will not be dispatched to a restricted buyer or target, regardless of other configuration.
Restricting publishers (Buyer and Target)
A buyer or target can block traffic from specific publishers. Pings from a restricted publisher are not dispatched to that buyer or target.
Restricting by Sub-ID
Any entity can block pings that carry specific Sub-IDs.
Entering Sub-IDs:
In the Cap and restrict block, find the Restricted Sub-IDs field.
Click to open the input area.
Paste or type your Sub-IDs separated by commas, spaces, newlines, or semicolons. You can paste a bulk list directly.
Click Apply to save.
Limits: maximum 100 Sub-IDs per entity, maximum 100 characters per Sub-ID. Sub-IDs that exceed these limits are discarded.
Sub-ID tag field (Publisher only)
The Sub-ID tag field on a Publisher controls which URL parameter the Relay reads to extract the Sub-ID from incoming pings. If your publisher sends Sub-IDs under a non-standard parameter name, set it here. If not configured, the account-level default applies.
Restrict by data quality
Data quality restrictions reject pings that carry invalid phone numbers or ZIP codes. These checks run before buyer dispatch — pings that fail do not reach buyers.
Restrict Invalid Phone
Available on: Buyer, Target
When enabled, pings with an unparseable or invalid phone number are rejected before a record is created — they do not appear in the Pings page and do not count toward stats.
Restrict Invalid ZIP
Available on: Buyer, Target
When enabled, pings with an invalid or missing ZIP code are blocked. If ZIP enrichment is off, the check runs before deduplication — the ping is rejected before a record is created. If ZIP enrichment is on, the check runs after the Relay attempts to resolve a ZIP; a ping that still has no valid ZIP at that point is blocked before buyer dispatch.
Interaction with ZIP enrichment: if ZIP enrichment is enabled for your org, the Relay attempts to resolve a ZIP from the phone number before this check runs. A ping that arrived without a ZIP may have one resolved by enrichment, and will then pass the Restrict Invalid ZIP check. Enabling both settings together is complementary: enrichment fills in the ZIP, the restriction validates it. See ZIP enrichment for details.
Limitations
Source restrictions block pings before buyer dispatch. A restricted ping never reaches the buyer and does not appear in the Pings page — no ping record is created.
Sub-ID limits are per entity. Maximum 100 Sub-IDs per entity, maximum 100 characters per Sub-ID. Values exceeding these limits are silently discarded.
Invalid phone and ZIP restrictions are Buyer and Target only. Publishers and Campaigns cannot restrict on data quality.
© 2026 A-Launch. All rights reserved.