Reporting
- Eskimi optimisation possibilities
- Dashboard overview page
- Bounce Rate Optimization Via Eskimi DSP
- Expectation vs. Reality: Clicks = Sessions?
- Report overview and how to download it?
- Footfall
- Visits
- Engaged sessions
- Reporting filters - what and how to check?
- Looker Studio integration (external)
- Filtered Impressions
- Reach Calculation on Eskimi DSP
- Campaign blocking reasons
Eskimi optimisation possibilities
The purpose of optimisation is to improve how well your campaign achieves its objectives. It involves modifying your advertising strategies in accordance with the data you collect. Eskimi DSP supports multiple optimisation techniques, which can be used to make adjustments in campaigns. Utilizing these possibilities, you will be able to reach the performance that aligns with your advertising goals.
The optimisation process itself can appear to be an easy task; however, it is essential not to get lost in multiple techniques and focus on the main campaign's objectives. Therefore, it is essential to:
- Set the right goal for your campaign
- Determine primary and secondary objectives to measure progress
- Use tools like Google Analytics (GA) to track and measure post-click performance.
Eskimi has two main types of optimisation:
1) Auto-Optimisation (Goals and Objectives included when creating the campaign)
2) Manual Optimisation (Targeting Optimisation Tool)
Eskimi DSP auto-optimisation (goals and objectives)
When you set specific campaign goals and objectives, such as awareness or traffic, it allows the auto-optimization algorithms to focus on those specific metrics. Eskimi DSP platform will then automatically optimize ad placements, creatives, and publishers to achieve predefined objectives.
Auto-optimisation works based on the set objective values in the primary and secondary campaign objective sections. That means that the system will bid on specific placements in order to determine if it meets objective values. If the placement will not meet the value, the system won't bid on it anymore.
Additionally, there is a possibility to set Pre-optimisation based on historical placement stats to enhance campaign performance. Historical placement stats refer to the data and performance metrics collected from previous campaigns' advertising placements.
Pre-optimization using historical placement stats streamlines campaign setup by leveraging proven successful strategies, reducing trial-and-error, and optimizing resource allocation. However, considering factors like advertising changes, consumer behavior, and platform updates is crucial for ongoing optimization.
Campaign objectives differ based on the campaign's type. Display campaign support auto-optimisation based on: CPC (cost per click), CTR (click through rate), CPA (cost per action), VR (viewability rate), CVR (click to visit rate), ER (engagement rate), CPE (cost per engagement), CPVst (cost per visit), SR (session rate), CPS (cost per session). Video campaign support: CPC, CTR, CPA, MVTR (minimum view-through rate), CPCVV (cost per completed video view), VVR (video viewability rate), SR, CPS.
Limitations:
- CPA auto-optimisation is supported only once Eskimi conversion pixel is implemented.
- CVR, SR, CPVst, and CPS auto-optimisation are supported only once Eskimi audience pixel is implemented.
- Eskimi DSP supports main and custom conversions' tracking; however, the optimisation can be done only by the main conversion performance.
Manual optimisation (Targeting optimisation)
The manual optimisation can be found in Eskimi DSP Targeting optimisation section. It allows us to analyze the campaign's performance (historical data) by listing segments and by all performance metrics, and optimize by pausing the individual elements, such as specific creative, exchange, and site.
Manual optimisation can be done by the following segments:
- exchange
- creative
- operating system
- browser
- operator
- app/site name
- package
- placement
Audience and conversion pixels
In order to track retargeting (site first party) audience, engaged sessions, and conversions, it is necessary to implement Eskimi tracking pixels on the landing page.
Implemented pixels allow you not only to see the metrics but also to optimize them, which is significantly important. With implemented pixels, you can see (just a few examples):
- From which websites or apps the conversions were made, and based on that, optimize the inventory
- What is the conversion rate of a particular creative, which allows for optimization of creatives
- Which browsers generate the most sessions, which gives the opportunity to optimize for browsers.
Audience and conversion pixels give you multiple opportunities to optimize for better performance; therefore, it is strongly recommended to implement them for multiple campaigns' objectives.
UTM
The UTM helps to indicate performance based on a specific segment on the Google Analytics side. For example, UTM content part {site_id} is crucial if we want to see the performance on GA side by site and site ID. This allows you to create the whitelist/blacklist based on the performance with specific site/app IDs and use it in Eskimi DSP campaign.
By default, ESKIMI UTMs include:
UTM source - eskimi
UTM medium - cpm
UTM campaign - {campaign_title}
UTM term - {creative_size}UTM content - eskimidsp_{site_id}
The UTMs' values and macros can also be updated based on the needs.
It is a pretty common case that the GA report shows a poor performance of a specific campaign in terms of session rate, bounce rate, etc., while the landing page of that particular campaign does not have any UTMs. That means that you are not able to filter the performance by site ID or any other segment on the GA side, therefore leaving you without any possibility to optimise the campaign on Eskimi DSP side.
Integral Ad Science (IAS), DoubleVerify (DV)
Integral Ad Science (IAS) and DoubleVerify (DV) trackers are most often used for tracking and evaluation of inventory and traffic quality, and viewability. By default, all these trackers evaluate performance by bundle/domain. However, it is possible to have more segments, such as campaign ID, creative ID, and more.
For example, the Eskimi DSP IAS pixel includes: campaign ID, site title, site ID, and creative size. These macros indicate that there will be a possibility to analyze the performance by the mentioned splits and to optimize them.
All of the mentioned trackers provide information on inventory and traffic quality, which can be used for manual optimisation on Eskimi DSP side. The manual optimisation can be done on IVT (invalid traffic), viewability, and other metrics, which can improve the overall performance.
Dashboard overview page
The Eskimi DSP Dashboard is a centralized view where advertisers can monitor and analyze their campaign performance over a selected period. It provides an aggregated summary of key campaign metrics, helping users track ad spend, impressions, clicks, and conversions in both numerical and graphical formats.
This dashboard enables advertisers to:
✅ Assess campaign effectiveness at a glance.
✅ Identify trends and patterns based on historical data.
✅ Compare multiple campaigns within the same timeframe.
✅ Access deeper insights for optimization and strategic adjustments.
How to Use the Dashboard?
1. Selecting the Time Period
The Eskimi DSP Dashboard allows you to filter data based on a specific time range:
- Locate the time selection drop-down menu in the top-right corner of the page.
- Choose from pre-set time ranges (e.g., Today, Last 7 Days, Last 30 Days) or select a custom date range.
- Click Apply to refresh the data accordingly.
By adjusting the time filter, advertisers can focus on short-term or long-term campaign performance and identify seasonal trends.
2. Understanding the Dashboard Metrics
At the top of the dashboard, key performance indicators (KPIs) are displayed in numeric format, including:
- Total Spend – The amount spent on campaigns within the selected period.
- Impressions – The total number of times ads were displayed.
- Clicks – The number of times users interacted with the ads.
- Conversions – The number of desired actions completed (e.g., purchases, sign-ups, or downloads).
🔹 Visualizing Performance: Below the numeric KPIs, a graphical representation of the data helps identify trends over time.
- Hovering over the data points reveals precise values for impressions, clicks, and conversions on specific dates.
- The graph updates dynamically when the time range is changed, making it easy to track performance fluctuations.
- Scrolling further provides detailed visual reports with additional breakdowns for deeper analysis.
3. Active Campaigns Overview
Directly beneath the main dashboard metrics, a list of all active campaigns is displayed. This section provides advertisers with a quick overview of individual campaign performance.
🔹 Key features of the Active Campaigns list:
- Each campaign’s spend, impressions, clicks, and conversions are displayed.
- Clicking on a campaign name redirects users to its detailed Report page, where more granular insights can be accessed.
- Users can compare performance across multiple campaigns to determine which strategies are working best.
4. Additional Insights & Performance Breakdown
Further down the dashboard, advertisers can access in-depth performance analysis, including:
✔️ Best-Performing & Worst-Performing Ads
- Displays a ranked list of top and low-performing ads based on engagement, conversion rates, and other key metrics.
- Helps advertisers identify creative elements that resonate best with their audience.
✔️ Platform & Operating System Distribution
- Shows which devices and platforms (mobile, desktop, tablet) are driving the most engagement.
- Breaks down performance by operating system (Android, iOS, Windows, etc.), allowing advertisers to optimize for the best-performing environments.
✔️ Delivery Map (By Hour or Weekday)
- A heatmap visualization displaying when ads receive the most impressions and interactions throughout the day or week.
- Helps advertisers optimize ad scheduling and budget allocation based on peak performance times.
Why Use the Eskimi DSP Dashboard?
The Eskimi DSP Dashboard is a powerful tool for campaign monitoring and optimization. By providing real-time insights and historical data, it enables advertisers to:
✅ Make data-driven decisions for better performance.
✅ Identify trends and adjust campaign strategies accordingly.
✅ Optimize ad placements, budgets, and targeting based on detailed reports.
By leveraging the Eskimi DSP Dashboard, advertisers can improve efficiency, maximize ROI, and refine their digital advertising strategies with ease. 🚀
Bounce Rate Optimization Via Eskimi DSP
When you’re advertising online, one of the key factors for successful ads is the quality of your website. If you’re trying to determine your website’s relevancy, Bounce Rate is the metric to follow. The importance of Bounce Rate as a measurement is that it shows how effective your website and marketing materials are. Bounce Rate measures visit quality. High Bounce Rate generally indicates that the site entrance (landing pages) aren't relevant to your visitors. Eskimi DSP gives the possibility to not only track Bounce Rate performance on Google Analytics via UTM tags, but to optimize the campaigns with the data collected. Therefore, we would like to share a few steps on how to export the necessary data to improve your digital campaign performance.
Bounce Rate Optimization Steps
Step #1: Go to the “Acquisition” section in your Google Analytics account.
Step #2: Go down to the “All Traffic” section.
Step #3: Click on “Source/Medium”.
Step #4: Via “Secondary Dimension” section filter “Ad Content”.
Step #5: Include “Source/Medium” containing “Eskimi / CPM”.
Step #6: Include “Bounce Rate” greater than 80.
Step #7: Export the data to a CSV file.
After doing all the necessary steps, share the file with your personal ad-ops member. He or she will exclude the irrelevant placements, hence keeping good digital advertising hygiene.
Expectation vs. Reality: Clicks = Sessions?
How often do you receive the question from the client: “Why Session volumes on 3rd party platform, Google Analytics, do not match clicks that the campaign has reached?” The question is a big head ace for advertisers. However, we wish to give clear answers and demolish the ongoing myth that Clicks = Sessions.
First, it is necessary to understand both concepts. Clicks indicate how many times your content was clicked by people while they were browsing online. Sessions, on the other hand, are a group of interactions that take place on your website within a given time frame.
Second, it is relevant to know the cause of the ongoing mismatch between different metrics. There are several reasons why these two numbers may not match:
Ads may be clicked multiple times. A user can click on an ad multiple times, but Google Analytics will only count these clicks as one session.
Returning users. A user can click on your ad, bookmark your site, and come back later during a different session. In this scenario, only one click would be recorded, while Google Analytics would recognize this as two separate sessions.
A user clicks and leaves quickly. A user may click on your ad but leave quickly by hitting the “back” or “stop” button before Google Analytics has a chance to load its tracking code and record the visit as a session. However, this would be counted as one click.
Session timeout. Google Analytics’ sessions are timed out after 30 minutes of inactivity. This means that if a user gets distracted and does something else during that time, then comes back and browses the site again later, it would be counted as two sessions.
Report overview and how to download it?
The report is a technical document, that details the diverse data collected during the campaign run. You can generate reports for a single campaign, as well as reports for all the campaigns under a particular account. To get more insights and analyse the performance of your campaign you can download reports directly from your Eskimi DSP account in several formats: .xls, .pdf, or .pdf (with charts).
Follow these simple steps to find the report.
1. When you log in to your account, select the "Reports" menu on the left of your screen.
2. Customise your report based on the available filters.
You can generate one report for all your campaigns or select a particular campaign. If you are running campaigns in several different countries, you can generate a report just for one of them by selecting the name of the country. You can choose the view of the report by date, by the campaign, or by country. Each of the filters is displayed in a convenient pop-up. And don't forget to choose the time period.
3. Now Scroll down and you'll be able to see the generated report together with data visualisation according to your selections. You can follow daily performance as well.
Scrolling down you will see insights about creatives, as well as technical insights ( operator, operating system, browser, device).
Time and placement performance shows campaign performance by weekdays.
There are many insights you can find on the report, if some of them are missing you can add missing filters by yourself.
How to download the report?
You can download the entire report in 3 different formats: .xls, .pdf or .pdf with charts.
Go on the Eskimi DSP - Reports - select the particular account and campaign/s - on the right side look for the 'Export' button (picture below), each button corresponds to the format of the report.
Footfall
You may think that driving people to your website is the only use for online advertising – but did you know that if you have a physical shop, Eskimi Ads can be key in bringing more customers through your business’ front door?
Footfall is a marketing term used by retailers for describing the number of customers that enter their stores.
Footfall attribution is a method for correlating digital marketing campaign impressions with actual store visits.
The primary goal is to initiate offline user activity to your physical store/location.
Footfall table example in the Eskimi DSP report (the footfall table is called Audience table)
Technology
Target users in different places. You can choose a wide range of targeting opportunities:
-
Country-wise - you can target the whole country. However, this may reduce the likelihood for people to visit your store if it in another part of the country.
-
Regional wise - this targeting would allow you to still reach a rather big amount of users, but it should bring better accuracy than country-wise targeting.
-
Radius targeting - To maximize the footfall results target users who are frequently next to your physical shop. Radius can differ depending on your goal, country, amount of shops, and other factors.
-
Other targeting opportunities - to reach good results the essential thing is to target app traffic. So you can use previous geofence audiences, impressions audiences from previous campaigns, interest audience and etc. Just don’t forget to enable only apps.
Footfall technology is based on various data segments. From which the primary is device IDs which is analyzed and compared from the users who have seen the ad and appeared in your physical store/location. Also, the solution takes into consideration real-time GPS location data. Meaning, that users are captured and analyzed in real-time.
Limitations - the majority of users will be reached on apps
Results
Eskimi DSP not only enables footfall measurement, but also helps your brand better understand the type of audience reached. It provides valuable audience insights based on the collected data and allows you to dive deeper into the results for a more comprehensive understanding of footfall performance.
|
Shop Name |
Total footfall users |
|
Shop 1 |
6,607 |
|
Shop 2 |
1,650 |
|
Shop 3 |
579 |
|
Shop 4 |
97,053 |
|
Shop 5 |
4,399 |
|
Shop 6 |
200 |
|
Shop 7 |
386 |
|
Shop 8 |
231 |
|
Shop Name |
Total Footfall Users |
Footfall Rate %* |
|
All Shops |
1,354,556 |
1.4% |
*Footfall rate is counted: users visited the shop / Total Reach
|
Traffic Source |
Footfall Users |
Footfall Rate % |
|---|---|---|
|
Region 1 |
44,555 |
1.21% |
|
Region 2 |
21,334 |
0.91% |
|
Region 3 |
10,341 |
0.56% |
|
Region 4 |
9,443 |
0.10% |
|
Traffic Source |
The Most Visited Shop |
|---|---|
|
Region 1 |
Shop 5 |
|
Region 2 |
Shop 1 |
|
Region 3 |
Shop 2 |
|
Region 4 |
Shop 4 |
These reports are provided as examples. Their level of detail depends on the campaign setup and segmentation. They are not automatically generated in the dashboard, but are prepared by our internal reporting team.
Media Planning
Budget: We strongly recommend starting from 10 000$. As with this budget, the client would receive the full package of footfall possibilities.
Audience Collection: Plan at least 2-3 days before the campaign launch for the audience collection.
Goal: Clearly understand the client’s objectives, what they aim to measure, and how they define success. Additionally, confirm whether they will track any metrics on their end.
Reporting: Inform the client that it will take up to 3 working days to prepare the report.
- Displays cross-matches between the targeted audience and the footfall audience.
- Displays the sum, not an overlap.
- The user can be cross-matched at any point in time after the ad is seen.
- Footfall reach shows users in sum, not unique users.
- The user will be calculated continuously every time he/she visits the location after seeing the ad.
Visits
Click to visit tracking is a helpful tool for optimising the visits, click to visit rate (CVR) or cost per visits (CPVst).
Visit metric measures the number of users who successfully arrive at an advertiser's website or landing page after interacting with an ad through a click.
Visit is counted:
- First second when user lands to campaign landing page and Eskimi DSP pixel fires
PROCESS:
1. SETUP
Setup Eskimi DSP Tracking pixel on the landing page.
1. Obtain the Tracking pixel code from Tracking pixels section.
2. Place the Tracking pixel code on the landing page.
More information about tracking pixel implementation guide
2. COLLECT
Collect click to visit data after launching the campaign and receiving clicks.
Collect the data to Eskimi DSP campaign reporting system: Visits, CVR (click to visit rate), CPVst (cost per visit).
3. OPTIMISE
Optimise only manually.
- Optimise manually on Targeting optimisation tool by Ad exchange, Creative, OS, Browser, Operator, App/Site.
Engaged sessions
Click to engaged session tracking is a helpful tool for optimising the sessions, session rate (SR) or cost per session (CPS).
ENGAGED SESSION definition - engaged session is a group of user interactions on the website that take place within a given time frame.
Engaged session is counted if:
- 2 or more page views were made
- The user spends 10s or more on the site
It's important to note that the engaged session differs from session.
PROCESS:
1. SETUP
Setup Eskimi DSP Tracking pixel on the landing page.
1. Obtain the Tracking pixel code from Tracking pixels section.
2. Place the Tracking pixel code on the landing page.
More information about tracking pixel implementation guide
2. COLLECT
Collect click to engaged session data after launching the campaign and receiving clicks.
Collect the data to Eskimi DSP campaign reporting system: Engaged Sessions, SR (engaged session rate), CPS (cost per engaged session).
3. OPTIMISE
Optimise automatically or manually.
- Optimise automatically by setting up rules for SR (engaged session rate) or/and CPS (cost per engaged session).
- Optimise manually on Targeting optimisation tool by Ad exchange, Creative, OS, Browser, Operator, App/Site.
Reporting filters - what and how to check?
Customise your report based on the available filters.
You can generate one report for all your campaigns or select a particular campaign. If you are running campaigns in several different countries, you can generate a report just for one of them by selecting the name of the country. You can choose the view of the report by date, by the campaign, or by country. Each of the filters is displayed in a convenient pop-up. And don't forget to choose the time period.
Filters
1. Campaign
- If you're running few different campaigns and want to see results few campaigns results, you need to select those particular campaigns.
You can search campaign by campaign name, once you select campaigns what you wanted to check - click "Select" and "Update report".
2. Country
- If you are running campaigns in several different countries, you can generate a report just for one of them by selecting the name of the country.
With such filter you will see results of campaigns which are running only in Kenya.
3. Sort
With this filter you can choose the view of the report by date, by the campaign, by country or by platform.
Sort by date:
There you see the results by selected time period:
Sort by campaign:
There you see the results by selected campaign:
Sort by country:
There you see the results by selected countries:
Sort by platform:
If you're running Multichannel campaign, there you're able to see campaign results by each platform.
4. Dates
There you can choose the time period of the campaign.
You can select and check Today, Yesterday, Last 7 days, This Month, Last Month data in the report, or you can manually select the dates. Once it done - do not forget click "Apply" and "Update report".
Looker Studio integration (external)
Introduction:
Eskimi offers a basic integration option with Google Looker Studio, enabling the transfer of fundamental metrics such as impressions, spend, and clicks. However, advanced data points, including media spend or top-performing creatives, are not currently supported.
Additionally, our Looker Studio code has not been officially approved by Google, as the approval process is both lengthy and resource-intensive. To date, Eskimi has not identified a strong need to pursue this certification. As a result, external users attempting to connect to Looker Studio may occasionally encounter the following error:
If you encounter this error and are unable to bypass it to connect to Looker Studio, there is no alternative workaround available. The only solution we can offer in such cases is to create a custom Looker Studio report tailored to the specific splits required by the user. Should this approach be chosen, the report will need to be built by our team, which may take some time. Additionally, users will not have the ability to independently add or modify splits within the report.
Guide:
To obtain the Looker Studio connector URL, you will need to provide an email address with access to the connector (this must be a Gmail domain). Once the Eskimi team has created the connector, the URL will be sent to the provided email.
Upon accessing the connector, you will likely encounter the following window:
You will have to click on "Hide" -> "Go to Copy of eskimi-datastudio-connector (unsafe)" -> Authorise (and authorise the connector with your gmail account to witch the access was shared).
If you will encounter the error that was mentioned in the "Introduction part" sadly there is no way to bypass it, and the only other is option to go with Looker Studio custom report.
If everything goes well, after Authorising the connector you will see this window:
*CAMPAIGN IDS - Here you can enter separate account Campaigns ID’s for which you want to obtain the data, has to be separate with the ; symbol. If you leave the campaign field empty it will take the last 15 campaigns from the account.
Data points you can access with the Looker Studio connector:
Please use the fields as Dimensions to avoid data discrepancies
Filtered Impressions
The Filtered Impressions widget is a helpful tool that shows the percentage of impressions that were filtered out from your campaigns. This can happen due to multiple reasons, such as specific targeting settings, creatives, budget & pacing limitations, and more. The percentage displayed indicates the number of impressions that didn't meet the specified criteria and were therefore excluded from the campaign.
Impressions can be filtered for the following reasons.
Pre-bid
The number of impressions not bought due to a pre-bid issue:
- Invalid traffic. Number of queries that were filtered because they are considered invalid traffic, e.g., fake clickers.
- Unauthorized seller (Ads.txt). Number of queries that were filtered because they are from Unauthorized Sellers.
- Rewarded ads are not supported. Number of queries that were filtered because the requests contain rewarded ads that are not supported.
Targeting
The number of impressions that were filtered due to targeting settings on your campaigns.
|
Targeting Setting |
Description |
|
Ad placement position |
Impressions that did not match ad positions selected in the campaign, e.g. above the fold. |
|
SEC & LSM |
Impressions that did not match the SEC & LSM targeting selected in the campaign. Read more here. |
|
Audience |
Impressions that did not match the audience targeting options used in the campaign, e.g., DMP audience or retargeting audience. |
|
Device |
Impressions that did not match the device targeting used in the campaign. It could be related to device type, OS, brand or model. |
|
Browser |
Impressions that did not match the targeted web browser in the campaign. |
|
Environment |
Impressions that did not match the environment (apps or sites) targeting options used in the campaign. |
|
Operator/ISP |
Impressions that were excluded due to operator/ISP targeting options used in the campaign. |
|
Location |
Impressions that did not match the location targeting of the campaign, e.g. country, cities, states, or zip codes. |
|
Language |
Impressions that were excluded due to language targeting options selected in the campaign. |
|
Brand Safety |
Impressions that did not match one or more brand safety settings set up in the campaign. |
|
IP addresses/ranges |
Impressions that did not match the targeted IP address or ranges of the campaign. |
|
Categories |
Impressions that did not match the app/site categories selection of the campaign. |
Creatives
The number of impressions that were filtered due to issues with the creatives selected in the campaign.
Display creative aspects
- Native ad is not SSL compliant. Impressions filtered due to non-SSL content, such as landing pages or third-party trackers using HTTP instead of HTTPS protocol.
- Banner JavaScript is not supported. Impressions that are filtered because JavaScript is not supported. This can be related to rich media, or JavaScript creatives and ad exchanges that don’t support JavaScript tags.
- Native ad asset is invalid. Native video creative image sizes are not suitable for native format alternative images.
- Video ad companion is not supported. Impressions are filtered because the potential placement does not support the companion banner.
- Banner topframe. Impressions that are filtered due to selected top frame placement targeting.
Video creative aspects
- Video ad skip is not supported. Impressions that are excluded due to placement limitations for selected video ad skip ability options.
- Video ad VPAID or OMID is not supported. Impressions that are filtered due to selected viewability tracking methods in creative settings. Learn more about VPAID or OMID.
- Video ad max duration exceeded. Impressions that are excluded because the video creative exceeds the allowed duration limit.
- Video ad VAST version is not supported. Impressions that are filtered due to the uploaded VAST tag version.
- Video ad start delay is not supported. Impressions that are filtered because of the start delay option that is applied in creative settings.
- Video ad min duration is not reached. Impressions that are filtered due to too-short video creative duration.
- Video ad MRAID is not supported. Impressions that are filtered as the placement does not support MRAID. Not all apps support MRAID, meaning that the impressions from the ones that don’t support it are getting filtered.
- Video placement. Impressions that are filtered due to selected video player placement (e.g., in banner, in article, in feed, interstitial, etc.).
- Video Linear/In-Stream placement. Impressions that are filtered due to selected video player requirements related to Linear/In-stream placements.
Placement limitations
- Creative category is not allowed. Impressions that are filtered due to a restricted creative category.
- Creative is not approved. Impressions that are filtered as the selected creative is pending approval or was rejected by the ad exchange.
Publisher restrictions
- Click URL excluded by publisher. Impressions that are filtered due to the declared click URL, which is excluded by the publisher.
- Product category excluded by the publisher. Impressions that are filtered due to detected sensitive advertised product category.
- Sensitive category excluded by the publisher. Impressions that are filtered due to the detected sensitive creative content category.
Budget & pacing
The number of impressions meeting targeting criteria with eligible creatives, but with bids exceeding any of the following limits:
- Frequency capping. Can be set on a campaign level. If the impressions limit for a user for a given period is reached, further impressions will be filtered out for the given period.
- The bid is too low. The bid price falls below the floor or exchange/publisher minimum price in an open auction. Increasing the bid might help to improve campaign performance by allowing the campaign to bid on placements with higher bid floors.
Reach Calculation on Eskimi DSP
Our DSP (Demand-Side Platform) includes a reporting system designed to track various metrics such as bids, impressions, and clicks. One important feature is the ability to calculate unique reach—the number of distinct users exposed to an ad—over time or throughout a campaign.
To achieve a balance between cost efficiency and performance, our platform uses Redis’s HyperLogLog (HLL) data structure for estimating unique reach. While this provides fast and memory-efficient approximate cardinality calculations, it introduces a small margin of error, which is a known behavior described in Redis's documentation.
How Redis HyperLogLog (HLL) Works
HyperLogLog is a probabilistic data structure used to estimate the number of unique elements in a dataset. Unlike traditional methods that store each element explicitly (which could require large amounts of memory), HLL works by hashing elements and using a clever algorithm to approximate the count of unique items. The benefit is that HLL can store and process large datasets with a memory footprint of only 12 KB, regardless of the number of elements.
For reach calculations on our platform, Redis HLL is used to count the number of unique users that have seen an ad. This allows us to quickly and efficiently calculate reach without the need for expensive, memory-intensive processes.
Minor Discrepancy and Its Impact on Reporting
Because HLL is an approximation algorithm, there can be a slight margin of error in its calculations, typically around 0.81% in Redis. This means that while HLL provides a close estimate of unique users, it may not always be perfectly accurate.
Example: Impression Capping and Reach Discrepancy
Consider a scenario where a campaign has strict impression capping, such as 1 impression per user. In this case, you might expect the reach to be exactly equal to the number of impressions (since each user should see only one ad). However, due to the nature of HLL’s probabilistic counting, there could be a slight discrepancy between the reported reach and impressions.
For example:
-
Expected reach = impressions: 1,000 unique users are shown 1 impression each.
-
Reported reach using HLL: Could be slightly less (e.g., 995) or slightly more (e.g., 1,005) than the exact number of impressions due to the algorithm’s margin of error.
Why This Small Discrepancy Exists
This discrepancy is inherent in how the HyperLogLog algorithm estimates counts. The algorithm trades off perfect accuracy for speed and efficiency, which is why the memory footprint remains small even for large datasets. The small error is generally negligible but becomes noticeable in edge cases, such as when the number of impressions per user is strictly controlled.
Key Takeaways
-
Efficient Reach Estimation: Our DSP platform leverages Redis HLL to efficiently calculate unique reach with minimal memory usage.
-
Small Margin of Error: Redis HLL introduces a small error (~0.81%), meaning that reach estimates may not always be exact.
-
Impression Capping Consideration: In scenarios with strict impression capping (e.g., 1 impression per user), small discrepancies between reported reach and impressions may occur due to HLL’s approximate nature.
While this method offers significant performance and cost benefits, it’s important to be aware of the potential for minor discrepancies in unique reach estimates. This is a natural outcome of using Redis HLL and is within the expected error range.
For cases where absolute accuracy is critical, alternative counting methods may be considered, but they typically involve higher memory and processing costs.
Campaign blocking reasons
Use this guide to understand each blocking reason, identify whether action is required, and determine the appropriate troubleshooting steps.
| rank | category | sub_category | Explanation of the sub category | Steps to follow | Recommendations |
| 1 | Auto-optimisation | of placements | A filter applied automatically by the platform's optimisation engine that excludes specific ad placements that have failed to meet the performance thresholds defined in the campaign's primary and secondary objective settings. The engine actively tests placements by bidding on them to gather performance data - if a placement does not meet the configured objective values (such as a target CPC, viewability rate), the system stops bidding on it automatically, concentrating future spend only on placements that demonstrably meet the required performance standards. | Review the primary and secondary objective values configured in the campaign - confirm they are realistic and achievable relative to current market benchmarks/current results. | Allow some time for the algorithm to learn. If objective values are set too aggressively, adjust them to more achievable thresholds that reflect realistic market performance benchmarks - this will slow the exclusion rate and preserve a broader eligible placement pool. |
| 2 | Targeting | app bundle/site domain package (include) | A filter that restricts ad delivery exclusively to a curated whitelist of specific app bundle IDs or site domains defined in an inclusion package applied to the campaign. Only bid requests originating from apps or sites present on that whitelist are eligible for bidding - all other inventory is filtered out before bidding, regardless of how well it matches all other targeting criteria. | Review the inclusion package to assess the number of app bundle IDs and site domains currently whitelisted and whether the list is broad enough to support delivery targets. | Regularly refresh and expand the inclusion package with new high-performing or contextually relevant apps and sites, using ongoing performance data to identify strong candidates for addition. |
| 3 | Targeting | City/State | Bid requests are blocked because the city or state targeting in the campaign doesn't match the user's location in the bid request. | Double-check geo targeting settings - ensure correct cities/states are selected. | If reach is low, consider expanding to regional or country-level targeting. |
| 4 | Bid is too low | CPM bid is lower than the floor price set by the publisher or exchange, so the bid is rejected. | Check the current bid vs. average floor prices in the campaign report. Increase CPM if needed. | Simplify the click URL structure where possible — reducing the number of redirect layers in the click tracking chain decreases the risk of triggering publisher-side URL validation rules and improves compatibility with Doubleclick's URL scanning and policy. | |
| 5 | Targeting | device type | A filter that restricts ad delivery to traffic originating from specific device types defined in the campaign's targeting settings - such as smartphones, tablets, desktop computers, or connected TVs (CTV). When a bid request is identified as originating from a device type not included in the campaign's allowed list, it is filtered out before bidding regardless of how well it matches all other targeting criteria. | Review the campaign's device type targeting configuration to confirm the inclusion list is intentional and aligned with the campaign's creative formats and audience strategy. | Expand the device type inclusion list where creatives and campaign objectives allow, to capture a broader share of available inventory across device categories and improve delivery scale. |
| 6 | Filtering | App/Site category (exclude) | A filter that blocks ad delivery on inventory belonging to specific content categories that have been explicitly blacklisted in the campaign's targeting settings. When a bid request originates from an app or site classified under an excluded category, it is filtered out before bidding - regardless of how well it matches all other targeting criteria | Review the full list of excluded categories to confirm each exclusion is intentional and strategically justified for the campaign's specific objectives. | Avoid overly broad category exclusions. Only exclude categories genuinely irrelevant or risky for the brand. Consider using whitelists instead for more controlled brand safety management. If a specific package needs to bypass category exclusions, use the 'Disable App/Site category exclusion' option in the campaign edit page for that package. |
| 7 | Auto-optimisation | of apps/sites (exclude) | A filter applied automatically by the platform's optimisation engine that identifies and excludes specific apps and sites that have failed to meet the performance thresholds defined in the campaign's primary and secondary objective settings. The engine actively tests apps and sites by bidding on them to gather performance data - if an app or site does not meet the configured objective values, the system stops bidding on it automatically, concentrating future spend only on publishers that demonstrably meet the required performance standards. | Review the primary and secondary objective values configured in the campaign - confirm they are realistic and achievable relative to current market benchmarks and available inventory quality. | If key inventory is being excluded, manually whitelist it or adjust the auto-optimisation sensitivity. If auto-optimisation is excluding critical inventory within a specific package, use the 'Disable auto optimisation' option for that package in the campaign edit page. |
| 8 | Filtering | creative size | A filter that blocks ad delivery when the campaign's creative dimensions do not match the ad slot dimensions declared by the publisher in the bid request. Publishers define the specific creative sizes their ad slots are designed to accommodate - such as 300x250, 728x90, or 320x50 - and when the campaign's active creative does not match any of the accepted sizes for that slot, the bid request is filtered out before bidding to prevent rendering failures or distorted ad displays. | Review the creative sizes currently active on the campaign and compare them against the most common ad slot dimensions available in the target market and exchange mix. | Prioritise producing creatives in the highest-volume sizes for the target market - in mobile-dominant markets this typically means 320x50, 300x250, and 320x480, while desktop inventory commonly favours 728x90, 300x250, and 160x600. |
| 9 | Filtering | IAB category | A filter that blocks ad delivery when the campaign's declared IAB content category is not accepted by the publisher or exchange receiving the bid request. IAB categories are a standardised taxonomy used across the programmatic ecosystem to classify both advertiser content and publisher inventory - publishers and exchanges declare which IAB categories they permit to serve on their inventory, and when the campaign's creative category falls outside those permitted classifications, the bid request is filtered out before bidding. | Review the IAB categories currently declared on the campaign's creative to confirm they are accurate, specific, and appropriate for the advertised product or service. | Review and update the campaign's IAB category classification to ensure it is as accurate and specific as possible - using a precise subcategory rather than a broad parent category can reduce filtering on publishers that block the parent category but accept more specific classifications within it. Where sensitive IAB categories are unavoidable due to the nature of the advertised product, identify and prioritise exchanges and publishers that explicitly accept those categories, and focus delivery on those supply sources. |
| 10 | Targeting | device model; SEC/LSM (include) | A filter that restricts ad delivery exclusively to users belonging to specific Socio-Economic Class (SEC) or Living Standard Measure (LSM) segments defined in the campaign's targeting settings. SEC and LSM are audience classification frameworks that group users into tiers based on indicators of income level, lifestyle, purchasing power, and living standards. When a bid request is associated with a user who does not fall within the campaign's allowed SEC or LSM segments, it is filtered out before bidding regardless of how well it matches all other targeting criteria. | Review the SEC or LSM segments currently included in the campaign to confirm the selection is appropriately broad and aligned with the realistic target audience size for the campaign's objectives. | If delivery is constrained by the narrowness of the SEC or LSM inclusion list, consider expanding the targeted segments to include adjacent socio-economic tiers with similar audience characteristics and purchasing behaviour profiles. |
| 11 | Targeting | device OS | A filter that restricts ad delivery to traffic originating from devices running specific operating systems defined in the campaign's targeting settings - such as Android, iOS, Windows, or macOS. When a bid request is identified as originating from a device running an OS not included in the campaign's allowed list, it is filtered out before bidding regardless of how well it matches all other targeting criteria. | Review the campaign's OS targeting configuration to confirm the inclusion list is intentional and aligned with the campaign's technical requirements and audience strategy. | Where the OS restriction is driven by app availability or technical compatibility, ensure the inclusion list reflects the exact OS versions supported by the app or creative, neither over-restricting nor under-restricting eligible traffic. |
| 12 | Targeting | audiences (include/exclude) | A filter that restricts or blocks ad delivery based on whether the user associated with a bid request belongs to a defined audience segment that has been either whitelisted (include) or blacklisted (exclude) in the campaign's targeting settings. Audience segments can be built from first-party data, third-party data providers, behavioral signals, retargeting lists, or platform-generated segments. When a bid request is associated with a user who does not match an included segment - or who does match an excluded segment - it is filtered out before bidding. | Review all audience inclusion and exclusion lists applied to the campaign to confirm each segment is intentional, up to date, and aligned with the campaign's current targeting strategy. | For inclusion targeting, regularly validate audience segment sizes and match rates across active exchanges — if a segment is too small or has a low match rate, consider expanding it with lookalike modeling, broadening the segment definition, or supplementing with additional complementary segments. |
| 13 | Targeting | Brand Blueprint | Brand Blueprint targeting is restricting delivery — bids are blocked because inventory doesn't meet the defined brand context criteria. | Go to contextual.eskimi.com and check the Brand Blueprint attached to the campaign. Use the Relevance Engine to test the blueprint against sample URLs from the target country to understand what is being matched or excluded. | If delivery is too low, review the blueprint prompt — it may be too restrictive. Use the Relevance Engine to analyze why certain URLs are not matching and adjust the prompt accordingly. Make sure the blueprint has been tested before campaign launch. |
| 14 | Targeting | app bundle/site domain package (exclude) | A filter that blocks ad delivery on specific apps and sites whose bundle IDs or domain addresses have been explicitly blacklisted in an exclusion package applied to the campaign. When a bid request originates from an app or site present on the exclusion package, it is filtered out before bidding - regardless of how well it matches all other targeting criteria. | Review all exclusion packages currently applied to the campaign - including those inherited from account or advertiser level - to assess the total number of blacklisted app bundle IDs and site domains. | Regularly audit all active exclusion packages to remove entries that are outdated, no longer strategically justified, or based on performance data from significantly different campaign conditions - keeping exclusion lists lean and current reduces unnecessary inventory loss. |
| 15 | Targeting | behavioural audience (include) | A filter that restricts ad delivery exclusively to users who have been classified within specific behavioural audience segments defined in the campaign's targeting settings. Behavioural audiences are built from observed user activity signals - such as browsing history, app usage patterns, content consumption behaviour, search intent, and past purchase activity - and grouped into segments that indicate particular interests, intentions, or lifestyle characteristics. When a bid request is associated with a user who does not match any of the campaign's included behavioural segments, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the behavioural audience segments currently included in the campaign to confirm each segment is relevant, sufficiently sized, and aligned with the campaign's audience strategy and performance objectives. | If behavioural segment match rates are low across the exchange mix, evaluate whether expanding to additional complementary segments - such as broader interest categories or lookalike audiences derived from the core behavioural segment - can recover scale while maintaining audience relevance. |
| 16 | Filtering | anti-fraud | Inventory is filtered out by Eskimi's internal anti-fraud system. This includes excluding users with unusually high daily app/site counts or page views, fake clickers, domain spoofers, and ads.txt mismatches — all indicating potentially fraudulent or non-genuine traffic. | Check the anti-fraud settings and review which specific anti-fraud options are enabled to understand what's being filtered. | Do not disable anti-fraud settings to increase delivery - this would compromise campaign quality. If a specific legitimate publisher is being blocked, investigate whether it's an ads.txt mismatch or domain spoofing issue separately. |
| 17 | Pacing | throttling request | When Even pacing is selected, the system distributes the daily budget evenly throughout the day. If too much traffic comes in at once, the system starts skipping some bid requests to prevent overspending — these skipped requests are registered as pacing throttling. | Check the pacing settings in the campaign. Verify whether Even or ASAP pacing is selected and review the daily budget amount. | If under-delivery is a concern, consider switching to ASAP pacing. However, be cautious with low daily budgets as ASAP pacing may cause overspending. If Even pacing is intentional, throttling is expected behaviour and not necessarily a problem. |
| 18 | Anti-fraud | high apps/sites count | A user's daily app/site count has exceeded Eskimi's predefined threshold, which is a common signal of bot or non-genuine traffic. | This is triggered by Eskimi's internal anti-fraud system. Check if 'Exclude Users with High Daily Apps/Sites Count' is enabled on the campaign approval page. | This is expected behaviour for fraud protection. Flag recurring sources for review. |
| 19 | Targeting | environment (apps/sites) | Bid requests are blocked because the inventory environment (app vs. mobile web vs. desktop web) doesn't match the targeting. | Check environment targeting settings in the campaign. | Ensure app and/or site environments are correctly selected based on campaign strategy. |
| 20 | Targeting | site contextual based on keywords | Bid requests are blocked because the site's URL or page content doesn't contain any of the keywords from the campaign's keyword targeting list. | Check the keyword list attached to the campaign. Verify whether URL keyword matching, content matching, or both are enabled. Also confirm that app traffic is excluded — contextual keyword targeting only works on site inventory, not apps. | If reach is too low, consider broadening the keyword list or switching from Exact Word to Contains Type match. Avoid overly short or generic keywords as they can cause unintended broad matching. Make sure the campaign is running on sites only, not apps. |
| 21 | Targeting | device browser | This filter restricts ad delivery to traffic coming from specific web browsers (e.g. Chrome, Safari, Firefox, Samsung Internet, UC Browser). When a campaign has browser targeting configured, bid requests from browsers not included in the target list are filtered out before bidding. | Review the campaign's browser targeting configuration to confirm the inclusion list is intentional and aligned with the campaign's technical requirements and audience strategy. | Unless browser targeting is strategically required, consider removing this restriction. |
| 22 | Targeting | app/site ID package (exclude) | This filter blocks ad delivery on specific apps or websites that have been explicitly added to an exclusion package. A package is a curated list of app/site IDs — when a bid request comes from any inventory source included in that exclusion package, it is filtered out and no bid is submitted. | Review the app/site ID exclusion package. | Review the list to ensure no valuable inventory is incorrectly excluded. |
| 23 | Filtering | App/Site category (include) | This filter restricts ad delivery to inventory that belongs to specific content categories (e.g. Sports, News, Entertainment, Finance). When a campaign has category inclusion targeting configured, bid requests from apps or sites that do not match any of the allowed categories are filtered out before bidding. | Review all exclusion packages currently applied to the campaign — including those inherited from account or advertiser level — to assess the total scope of blacklisted apps and sites. | Regularly audit all active exclusion packages to remove entries that are outdated, no longer strategically justified, or based on performance data from significantly different campaign conditions — keeping exclusion lists lean and current reduces unnecessary inventory loss. |
| 24 | Targeting | Video rewarded placement | This filter restricts ad delivery based on whether the video placement is of the rewarded type. Rewarded video is a specific ad format - typically used in mobile gaming apps - where the user opts in to watch a full video ad in exchange for an in-app reward (e.g. extra lives, coins, or premium content). When a campaign does not support or include rewarded placements, bid requests from these environments are filtered out before bidding. | Review the campaign's rewarded placement targeting configuration to confirm the inclusion or exclusion setting is intentional and aligned with the campaign's creative format and KPI strategy. | If rewarded placements are currently excluded, evaluate whether including them could unlock meaningful additional inventory scale — particularly for mobile campaigns operating in gaming-heavy markets where rewarded is the dominant video format. |
| 25 | Filtering | user bid capping | This filter limits how many times a single user can be shown an ad within a defined time period. When a campaign has frequency capping configured at the bidding level, bid requests from users who have already reached their impression cap are filtered out before bidding — even if the request is otherwise fully eligible. | Review the user bid cap configuration — confirm the cap threshold and time window are appropriately calibrated for the campaign's audience size and delivery targets. | Adjust the bid cap if under-delivery is an issue. Be careful not to confuse bid capping with impression capping — both affect delivery but at different stages. |
| 26 | Targeting | site brand-safety | This filter restricts ad delivery to inventory that meets defined brand safety standards. When a campaign has brand safety targeting configured, bid requests from apps or sites that are flagged as unsafe or do not meet the required safety thresholds are filtered out before bidding - protecting the advertiser's brand from appearing alongside harmful, inappropriate, or low-quality content. | Review the brand safety targeting configuration to confirm the safety thresholds and content restrictions are appropriately calibrated for the campaign's specific context and risk tolerance. | Regularly review and calibrate brand safety thresholds to ensure they reflect the campaign's actual risk tolerance — overly conservative settings applied uniformly across all campaigns can unnecessarily restrict inventory access for campaigns where a more relaxed threshold would be appropriate. |
| 27 | Targeting | operator/ISP (exclude) | This filter blocks ad delivery to traffic originating from specific mobile network operators or internet service providers (ISPs) that have been explicitly excluded in the campaign settings. When a bid request is identified as coming from a blacklisted operator or ISP, it is filtered out before bidding - regardless of how well the request matches other targeting criteria. | Review all operator and ISP exclusions currently applied to the campaign — including those inherited from account or advertiser level — to confirm each exclusion is intentional and strategically justified. | Periodically audit all active operator and ISP exclusions to confirm each remains strategically justified — removing exclusions that are outdated, based on stale performance data, or inherited from account-level settings without specific relevance to the current campaign. |
| 28 | Targeting | IP addresses/ranges (include) | This filter restricts ad delivery exclusively to traffic originating from specific IP addresses or defined IP ranges that have been whitelisted in the campaign settings. When a bid request comes from an IP address that falls outside the allowed list or range, it is filtered out before bidding - regardless of how well it matches all other targeting criteria. | Verify the IP addresses applied in the campaign are correct and up to date. | Ensure IP addresses/ranges are not too narrow. |
| 29 | Anti-fraud | high page views | A user's daily page view count has exceeded Eskimi's predefined threshold, indicating potentially non-genuine traffic. | Check if 'Exclude Users with High Daily Page Views' is enabled on the campaign approval page. | Expected behaviour — no action needed. |
| 30 | Filtering | creative is not approved on ad exchange | This filter blocks ad delivery when the campaign's creative has not received approval from the ad exchange on which the bid request originates. Each ad exchange maintains its own creative review and approval process, and only pre-approved creatives are eligible to serve on that exchange. When a bid request comes from an exchange where the creative is pending review or has been rejected, it is filtered out before bidding. | Check the approval status of all active creatives across every exchange connected to the campaign — identify which exchanges have pending, rejected, or expired approvals contributing to filtering. | When updating or replacing creatives mid-flight, initiate the re-review process on all affected exchanges immediately to minimise the approval gap and avoid unnecessary delivery interruption. |
| 31 | Targeting | site contextual | This filter restricts ad delivery based on the contextual classification of the site or app content, ensuring ads appear only in environments whose subject matter or thematic context aligns with the campaign's defined contextual targeting criteria. When a bid request comes from a site or app whose content category does not match the allowed contextual segments, it is filtered out before bidding. | Review the contextual targeting configuration to confirm the allowed topics, keywords, and content classifications are appropriately broad and accurately reflect the campaign's desired content environment. | Expand contextual segments to include related or complementary content topics and categories where the campaign's audience is likely to be present — broadening beyond the most obvious thematic match can meaningfully recover inventory scale without compromising contextual relevance. |
| 32 | Targeting | sentiments | Bid requests are blocked because the page's detected sentiment (positive, negative, neutral) doesn't match the sentiment targeting set in the campaign. | Check sentiment targeting settings in the Contextual Targeting section of the campaign. | Avoid selecting only one sentiment unless strategically necessary — adding Neutral or Unknown can significantly improve reach. |
| 33 | Filtering | no consent for tracking (DNT) | User has opted out of tracking (Do Not Track), and the filtering rules prevent bidding on such users. | This is a compliance-driven filter. | No action needed — this is expected behaviour. |
| 34 | Filtering | no consent for tracking (LMT) | User has Limit Ad Tracking enabled on their device. | This is a compliance-driven filter. | No action needed — this is expected behaviour. |
| 35 | Filtering | impression capping | This filter limits the total number of impressions a single user can receive from a campaign within a defined time period. When a user has already reached their impression cap, all subsequent bid requests from that user are filtered out before bidding - even if the request is otherwise fully eligible across all other targeting criteria. | Review impression capping settings. | Adjust impression frequency cap if reach is too limited. For specific packages where impression capping is causing delivery issues, consider enabling the 'Disable impression capping' option for that package in the campaign edit page. |
| 36 | Auto-optimisation | of visits/sessions | This filter is applied automatically by the platform's optimisation engine, which progressively limits or excludes inventory sources - such as specific apps, sites, exchanges, or audience segments - that have historically failed to drive visits or sessions for the campaign. Rather than a manually configured targeting rule, this is a dynamic, data-driven filter that evolves as the campaign accumulates performance data. This filtering is applicable only if there is Eskimi pixel added on the landing page used in the campaign. | Review the visit or session objective values configured in the campaign — confirm they are realistic and achievable relative to current market benchmarks and the quality of available inventory in the target geography. | Disable visits/sessions auto-optimisation in approval page if delivery is too restricted. |
| 37 | Targeting | language | This filter restricts ad delivery to inventory where the content language of the site or app matches the language or languages defined in the campaign's targeting settings. When a bid request comes from an environment whose declared content language does not align with the campaign's allowed language list, it is filtered out before bidding. | Review the campaign's language targeting configuration to confirm the allowed language list is appropriately comprehensive and aligned with the campaign's creative language and audience strategy. | If traffic is being excluded, consider including all languages - especially unknown - language data is often not sent via bid request. Keep in mind that lanuage targeting applies only on sites, not on apps. |
| 38 | Filtering | creative subtype IBV is not supported | This filter blocks ad delivery when the campaign's creative is of the In-Banner Video (IBV) subtype but the publisher's ad slot or exchange does not declare support for this format. IBV is a video ad that plays within a standard banner ad container rather than a dedicated video player, and not all inventory sources are configured to accept or render it correctly. When a bid request comes from an environment that does not support IBV, it is filtered out before bidding. | Identify which exchanges and publishers are generating the highest volume of IBV compatibility filtering to determine where format support is most limited across the active supply mix. | Always maintain VAST video creatives alongside IBV creatives to capture the broader video inventory pool that does not declare IBV support — ensuring delivery continuity across the full range of available placements rather than restricting the campaign to IBV-compatible inventory only. |
| 39 | Targeting | placement ID package (include) | This filter restricts ad delivery exclusively to a curated set of specific ad placements that have been whitelisted in an inclusion package. A placement ID package is a predefined list of exact ad slot identifiers - unique IDs assigned to individual ad units within apps or sites - and only bid requests originating from placements on that whitelist are eligible for bidding. All other inventory, regardless of how well it matches other targeting criteria, is filtered out before bidding. | Review the placement ID inclusion package to assess the number of whitelisted placement IDs and evaluate whether the list is sufficiently broad to support the campaign's delivery targets at the required pace. | Regularly refresh and expand the inclusion package with new high-performing placement IDs identified through ongoing performance analysis — a static whitelist that is not actively maintained will gradually shrink in effective coverage as placements change or become unavailable. |
| 40 | Doubleclick | creative category is not allowed | This filter blocks ad delivery when the campaign's creative is classified under a content category that is explicitly restricted or not permitted by the publisher, ad exchange, or supply-side platform (SSP) receiving the bid request. Publishers and exchanges maintain their own lists of allowed and blocked creative categories to protect their content environment and comply with their editorial policies - when a creative's declared category conflicts with those restrictions, the bid request is filtered out before bidding. | Check creative category classification. | Re-categorise creative if incorrectly classified, or find publishers that accept the category. |
| 41 | Anti-fraud | domain spoofing | This filter blocks ad delivery on inventory where the declared domain in the bid request does not match the actual domain serving the ad - a fraudulent practice known as domain spoofing. Domain spoofing occurs when a low-quality or non-brand-safe publisher misrepresents their inventory as originating from a premium or reputable domain in order to attract higher bids. The anti-fraud layer detects these mismatches and filters out spoofed bid requests before bidding, protecting campaign budget from being spent on fraudulent inventory. | This is blocked by anti-fraud mechanisms. | No action needed — expected behaviour. Flag if this is disproportionately high for a specific source. |
| 42 | Targeting | ad placement position | This filter restricts ad delivery based on the physical position of the ad unit within the page or app screen. Ad placement position defines where an ad slot appears relative to the content — such as above the fold, below the fold, in the header, footer, or sidebar - and when a campaign has specific placement position targeting configured, bid requests from positions not included in the allowed list are filtered out before bidding. | Check ad placement position targeting in the campaign. Use Stats tool to see which positions are available. | If placement position data is not provided by the publisher, the impression may fall under 'Other' or get excluded entirely. Be sure the selected ad placement positions match the creative sizes. Unless placement position is a strict requirement, it's better to include all options or leave this targeting open to avoid unnecessary delivery loss. |
| 43 | Targeting | operator/ISP (include) | This filter restricts ad delivery exclusively to traffic originating from specific mobile network operators or internet service providers (ISPs) that have been whitelisted in the campaign's targeting settings. When a bid request is identified as coming from an operator or ISP that is not on the allowed list, it is filtered out before bidding - regardless of how well the request matches all other targeting criteria. | Review the operator and ISP inclusion list to confirm each whitelisted network is intentional and strategically justified relative to the campaign's audience and performance objectives. | In markets with fragmented operator landscapes, evaluate whether expanding the inclusion list to cover additional operators with similar audience profiles can recover delivery scale without meaningfully compromising the campaign's network-specific targeting objectives. |
| 44 | Filtering | Video ad max duration exceeded | This filter blocks ad delivery when the campaign's video creative exceeds the maximum video ad duration permitted by the publisher's ad slot or exchange. Publishers define the maximum length of video ads they are willing to accept in their inventory, and when the campaign's creative runtime is longer than that declared limit, the bid request is filtered out before bidding - preventing a creative from being served in an environment that cannot or will not accommodate its full length. | Review the runtime of all active video creatives on the campaign and compare them against the most commonly declared maximum duration thresholds across the target exchange and publisher mix. | Produce and activate multiple creative versions of varying lengths — such as 6-second, 15-second, and 30-second cuts alongside the full-length version — ensuring the campaign can compete for the broadest possible range of video inventory while maintaining message effectiveness across different placement contexts. |
| 45 | Targeting | device brand (include) | This filter restricts ad delivery exclusively to traffic originating from devices manufactured by specific brands that have been whitelisted in the campaign's targeting settings. When a bid request is identified as coming from a device whose manufacturer or brand is not on the allowed list, it is filtered out before bidding - regardless of how well the request matches all other targeting criteria. | Video ad video file type is not supported. | Broaden the list if reach is too low. |
| 46 | Filtering | Video ad video file type is not supported | This filter blocks ad delivery when the video creative's file format or codec is not supported by the publisher's ad slot or exchange receiving the bid request. Publishers and exchanges declare the video file types and encoding formats they are technically capable of rendering, and when the campaign's creative is encoded in a format outside that declared compatibility list, the bid request is filtered out before bidding - preventing a creative from being served in an environment where it cannot play correctly. | Review the video file formats currently active on the campaign and compare them against the most commonly declared supported formats across the target exchange and publisher mix. | Always ensure the video creative is available in MP4 format as the primary file type — MP4 is the most universally accepted video format across the majority of exchanges, publishers, and device environments and should be the baseline creative asset for all video campaigns. |
| 47 | Targeting | ad placement position (interstitial) | This filter restricts ad delivery based on whether the ad slot is classified as an interstitial placement. Interstitial ads are full-screen ads that cover the entire app or page interface, typically appearing at natural transition points - such as between app screens, game levels, or page loads - and requiring the user to actively dismiss them before continuing. When a campaign explicitly targets or excludes interstitial placements, all bid requests that do not match the configured interstitial setting are filtered out before bidding. | Review the campaign's interstitial targeting configuration to confirm the inclusion or exclusion setting is intentional and aligned with the campaign's creative format, audience strategy, and placement quality requirements. | Where interstitial placements are excluded, periodically reassess whether the exclusion remains justified based on current performance data — interstitial inventory can deliver strong viewability and engagement metrics that may outweigh the user experience concerns that originally motivated the exclusion. |
| 48 | Filtering | Video ad skip is not supported | This filter restricts ad delivery based on whether the ad slot is classified as an interstitial placement. Interstitial ads are full-screen ads that cover the entire app or page interface, typically appearing at natural transition points - such as between app screens, game levels, or page loads - and requiring the user to actively dismiss them before continuing. When a campaign explicitly targets or excludes interstitial placements, all bid requests that do not match the configured interstitial setting are filtered out before bidding. | Review the campaign's skippability configuration to confirm the setting is intentional and aligned with the campaign's KPI strategy and creative format requirements. | Where non-skippable targeting is significantly constraining delivery, evaluate whether the campaign's completion rate objectives could be achieved through alternative means — such as rewarded video or high-viewability placements — that deliver strong completion metrics without restricting the eligible pool to non-skippable inventory only. |
| 49 | Filtering | advertiser Ad domain is restricted | This filter blocks ad delivery when the advertiser's declared ad domain - the domain associated with the ad's landing page or brand — is explicitly restricted or blacklisted by the publisher, exchange, or supply-side platform (SSP) receiving the bid request. Publishers and exchanges maintain lists of ad domains they do not permit to serve on their inventory, and when the campaign's declared ad domain matches an entry on those restriction lists, the bid request is filtered out before bidding. | Identify which exchanges and publishers are generating the highest volume of ad domain restriction filtering to determine where the restrictions are most concentrated and impactful. | Where domain restrictions are driven by past policy violations or ad quality flags, work directly with the affected exchanges to understand the specific violation, remediate the underlying issue, and initiate the domain reinstatement process — most exchanges provide a formal appeals or reapproval pathway for previously flagged domains. |
| 50 | Targeting | age group | This filter restricts ad delivery to traffic associated with users who fall within specific age groups defined in the campaign's targeting settings. When a bid request carries user age data that does not match any of the campaign's allowed age segments, it is filtered out before bidding - ensuring the ad is served only to audiences within the intended demographic range. | Review the age group inclusion list to confirm the selected segments are appropriately broad and accurately reflect the campaign's realistic target demographic and audience size requirements. | Where age signal coverage is low across the campaign's active exchanges, evaluate whether accepting traffic with undeclared age data is appropriate — particularly for campaigns where age targeting is a preference rather than a regulatory requirement, as including age-unknown traffic can meaningfully recover delivery volume without genuine demographic risk. |
| 51 | Targeting | device brand (exclude) | This filter blocks ad delivery to traffic originating from devices manufactured by specific brands that have been explicitly blacklisted in the campaign's targeting settings. When a bid request is identified as coming from a device whose manufacturer or brand matches an entry on the exclusion list, it is filtered out before bidding - regardless of how well the request aligns with all other targeting criteria. | Review all device brand exclusions currently applied to the campaign to confirm each is intentional, strategically justified, and based on current rather than outdated performance data. | Periodically audit all active device brand exclusions to confirm each remains strategically justified — removing exclusions that are outdated, based on stale performance data, or no longer relevant to the current campaign's audience and objectives. |
| 52 | Targeting | Video placement | This filter restricts ad delivery based on the specific type of video placement declared by the publisher in the bid request. Video placement types define how and where a video ad appears within the content environment - such as in-stream, in-banner, in-article, or in-feed - and when a campaign has specific video placement types configured, bid requests from placement types not included in the allowed list are filtered out before bidding. | Review the campaign's video placement type configuration to confirm the inclusion list is intentional and aligned with the campaign's creative format, KPI strategy, and audience objectives. | Where delivery is constrained by a narrow video placement type inclusion list, evaluate whether complementary placement types that align with the campaign's creative format and performance objectives could be added to broaden the eligible inventory pool without meaningfully compromising content context or audience quality. |
| 53 | Filtering | Video ad VAST version is not supported | This filter blocks ad delivery when the VAST (Video Ad Serving Template) version used by the campaign's video creative is not supported by the publisher's video player or ad serving environment declared in the bid request. VAST is the industry-standard XML-based protocol that defines how video ads are served, tracked, and rendered - and publishers declare which VAST versions their video players are capable of interpreting. When the campaign's creative relies on a VAST version outside the publisher's supported range, the bid request is filtered out before bidding to prevent serving failures. | Identify the VAST version currently being used by the campaign's active video creatives and compare it against the most commonly declared supported VAST versions across the target exchange and publisher mix. | Ensure the campaign's ad server is configured to serve creatives across multiple VAST versions simultaneously — providing VAST 2.0 and 3.0 fallbacks alongside newer VAST 4.x versions ensures the campaign can compete for the broadest possible range of video inventory without sacrificing advanced feature availability on publishers that support newer versions. |
| 54 | Filtering | bid capping | This filter limits the maximum price the campaign is willing to pay for a single impression. When a bid request carries a floor price or market clearing price that exceeds the campaign's defined bid cap, the request is filtered out before bidding - preventing the campaign from submitting a bid that would exceed its maximum allowable cost per impression. | Compare the campaign's current bid cap against average floor prices across the target exchanges and markets — identify the gap between the cap and prevailing market prices to understand how restrictive the current setting is relative to available inventory. | Review and adjust the bid cap to better reflect current market floor prices in the target inventory and geography — a cap that was appropriate at campaign setup may become increasingly restrictive as market conditions evolve, requiring periodic recalibration throughout the campaign flight. |
| 55 | Filtering | targeting segment (exclude) | A filter that blocks ad delivery to users who belong to specific audience segments that have been explicitly blacklisted in the campaign's targeting settings. Targeting segment exclusions can be applied across a wide range of segment types - including behavioural, demographic, interest-based, retargeting, or platform-generated segments - and when a bid request is associated with a user who matches any excluded segment, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | This filter limits the maximum price the campaign is willing to pay for a single+G56 impression. When a bid request carries a floor price or market clearing price that exceeds the campaign's defined bid cap, the request is filtered out before bidding - preventing the campaign from submitting a bid that would exceed its maximum allowable cost per impression. | Periodically audit all active segment exclusions to confirm each remains strategically justified - removing exclusions that are no longer relevant, have grown too large relative to the available audience, or were added based on conditions that no longer apply to the current campaign. |
| 56 | Filtering | Banner ad file type is not supported | A filter that blocks ad delivery when the banner creative's file format is not supported by the publisher's ad slot or exchange receiving the bid request. Publishers and exchanges declare the banner file types they are capable of rendering - such as JPEG, PNG, GIF, or HTML5 - and when the campaign's active creative is delivered in a format outside that declared compatibility list, the bid request is filtered out before bidding to prevent rendering failures or blank placements. | Identify which exchanges and publishers are generating the highest volume of this filtering reason to determine where format incompatibility is most concentrated. | Always upload creative assets in multiple formats - include a static image fallback such as JPEG or PNG alongside HTML5 or animated versions to maximise compatibility across the broadest possible range of inventory. |
| 57 | Filtering | Video ad VPAID or OMID is not supported | A filter that blocks ad delivery when the campaign's video creative relies on VPAID (Video Player Ad-Serving Interface Definition) or OMID (Open Measurement Interface Definition) but the publisher's video player does not declare support for these frameworks. VPAID enables interactive functionality and real-time communication between the ad and the video player, while OMID provides a standardised interface for third-party viewability and verification measurement. When the required framework is unavailable in the serving environment, the bid request is filtered out before bidding to prevent tracking failures, measurement gaps, or broken ad experiences. | Determine whether the filtering is driven by VPAID, OMID, or both framework requirements - understanding which framework is causing the majority of filtering focuses resolution efforts appropriately. | Migrate VPAID creatives to VAST-only formats where possible - VAST is universally supported and eliminates VPAID-related compatibility filtering across mobile, CTV, and increasingly desktop inventory. |
| 58 | Targeting | multi SIM operator | A filter that restricts or blocks ad delivery based on whether the user's device is operating with multiple SIM cards simultaneously. Multi SIM targeting allows campaigns to include or exclude traffic from users identified as using dual-SIM or multi-SIM devices, where more than one mobile network operator is active on the same device at the same time. When a bid request's multi SIM operator signal does not match the campaign's configured targeting setting, it is filtered out before bidding. | Assess the volume and share of bid requests being filtered for this reason relative to total filtered traffic to understand the overall delivery impact. | In markets with high dual-SIM adoption, carefully evaluate whether excluding multi-SIM users is strategically justified - doing so may unnecessarily eliminate a large and valuable share of the available audience without a proportionate benefit to campaign performance. |
| 59 | Doubleclick | sensitive category excluded by publisher | A filter that blocks ad delivery when the campaign's creative is classified under a sensitive content category that has been explicitly excluded by the publisher through Google's Doubleclick ad serving platform. Publishers using Doubleclick (now part of Google Ad Manager) can configure their inventory to block ads from specific sensitive advertiser categories — such as alcohol, gambling, weight loss, or political content — and when the campaign's creative falls under an excluded category, the bid request is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Identify which publishers and exchanges are generating the highest volume of Doubleclick sensitive category filtering to determine where restrictions are most concentrated across the active supply mix. | Review the sensitive category classification of the campaign's creative in Doubleclick and ensure it is as accurate and specific as possible — using the most precise available subcategory rather than a broad parent category can reduce the scope of publisher exclusions triggered by overly general classifications. |
| 60 | Doubleclick | click URL excluded by publisher | A filter that blocks ad delivery when the campaign's click tracking URL is identified as restricted or excluded by the publisher through Google's Doubleclick ad serving platform. Publishers using Doubleclick can configure their inventory to block specific click tracking domains, redirect patterns, or URL structures that do not meet their technical standards or policy requirements — and when the campaign's declared click URL matches an excluded pattern or domain, the bid request is filtered out before bidding regardless of how well it aligns with all other targeting and creative criteria. | Identify which publishers and exchanges are generating the highest volume of Doubleclick click URL filtering to determine where URL restrictions are most concentrated across the active supply mix. | Simplify the click URL structure where possible — reducing the number of redirect layers in the click tracking chain decreases the risk of triggering publisher-side URL validation rules and improves compatibility with Doubleclick's URL scanning and policy enforcement systems. |
| 61 | Filtering | Video ad start delay is not supported | A filter that blocks ad delivery when the campaign's video creative start delay configuration does not match the start delay type declared by the publisher's video placement in the bid request. Video start delay defines when within the content stream the ad is served — such as pre-roll (before content begins), mid-roll (during content), or post-roll (after content ends) — and when the campaign's allowed start delay types conflict with what the publisher's placement declares, the bid request is filtered out before bidding to prevent serving the ad in an unintended or technically incompatible position within the content stream. | Review the campaign's start delay targeting configuration to confirm the allowed start delay types are intentional and aligned with the campaign's creative format, KPI strategy, and content environment objectives. | Where pre-roll only targeting is significantly constraining delivery, evaluate whether including mid-roll positions could meaningfully expand the eligible inventory pool without compromising the campaign's core content context objectives — mid-roll placements within high-quality long-form content can deliver strong attention and completion metrics comparable to pre-roll in many environments. |
| 62 | Filtering | EU GDPR TCF vendor | A filter that blocks ad delivery when the campaign's demand-side platform, tracking vendor, or technology partner is not registered or consented to under the IAB's Transparency and Consent Framework (TCF) for the user associated with the bid request. The TCF is the industry-standard compliance framework governing how user consent for data processing is collected, stored, and communicated across the programmatic advertising supply chain under the EU General Data Protection Regulation (GDPR). When a bid request carries a consent string that does not include valid consent for one or more vendors required by the campaign to process user data, the bid request is filtered out before bidding to ensure the campaign operates within the boundaries of the user's declared consent preferences. | Identify the TCF vendor IDs required by the campaign's technology stack — including DSP, audience data providers, and measurement partners — and confirm they are correctly registered in the IAB TCF Global Vendor List. | Ensure all vendors in the campaign's technology stack are correctly registered on the IAB TCF Global Vendor List and that their vendor IDs are accurately declared in all active creative and tracking configurations — incorrect or missing vendor ID declarations can cause consent filtering that appears to be a user rejection issue but is actually a technical registration error. |
| 63 | Targeting | data consumption | A filter that restricts ad delivery based on the user's mobile data consumption type or connectivity status at the time of the bid request — such as whether the user is connected via mobile data (2G, 3G, 4G, 5G) or Wi-Fi. When a bid request carries a connectivity signal that does not match the campaign's allowed data consumption types, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the campaign's data consumption targeting configuration to confirm the allowed connectivity types are intentional and aligned with the campaign's audience context strategy and creative format requirements. | Where data consumption targeting is driven by creative format performance requirements — such as avoiding slow-loading rich media on 2G connections — evaluate whether excluding only the lowest bandwidth connection types rather than applying broad mobile data or Wi-Fi exclusions could achieve the same quality objective with less aggressive inventory restriction. |
| 64 | Filtering | Video ad min duration is not reached | A filter that blocks ad delivery when the campaign's video creative runtime is shorter than the minimum video ad duration required by the publisher's ad slot or exchange declared in the bid request. Publishers define not only maximum but also minimum acceptable ad lengths for their video placements — ensuring that ads served within their content meet a baseline duration threshold that aligns with their content structure, user experience standards, or monetisation requirements. When the campaign's creative is shorter than that declared minimum, the bid request is filtered out before bidding. | Review the runtime of all active video creatives on the campaign and compare them against the minimum duration thresholds declared across the target exchange and publisher mix. | Produce and activate multiple creative versions of varying lengths alongside the primary short-form asset — ensuring the campaign has longer creative variants available to serve on publishers with minimum duration requirements that the short-form creative cannot meet. |
| 65 | Targeting | Video skip duration | A filter that restricts ad delivery based on the number of seconds after which the user is permitted to skip the video ad. Video skip duration defines the minimum watch time enforced before the skip option becomes available to the user — such as 5 seconds for standard skippable pre-roll formats — and when the skip duration declared by the publisher's placement does not match the campaign's allowed skip duration configuration, the bid request is filtered out before bidding. | Review the campaign's skip duration targeting configuration to confirm the allowed skip duration values are intentional and appropriately calibrated relative to the campaign's brand exposure and completion rate objectives. | Where skip duration targeting is significantly constraining delivery, evaluate whether broadening the allowed skip duration range — such as accepting both 5-second and 10-second skip delays alongside longer thresholds — could meaningfully recover inventory scale without materially compromising the campaign's brand exposure objectives. |
| 66 | Targeting | Banner topframe | |||
| 67 | Doubleclick | product category excluded by publisher | A filter that blocks ad delivery when the campaign's advertised product or service falls within a content category that has been explicitly excluded by the publisher through Google's Doubleclick ad serving platform. Unlike sensitive category exclusions — which target broadly restricted content types — product category exclusions are more granular, allowing publishers to block specific advertiser product categories that conflict with their editorial positioning, audience profile, or commercial relationships. When the campaign's declared product category matches a publisher's Doubleclick product category exclusion configuration, the bid request is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Identify which publishers and exchanges are generating the highest volume of Doubleclick product category filtering to determine where exclusions are most concentrated across the active supply mix. | Review the product category classification of the campaign's creative in Doubleclick and ensure it is as accurate and specific as possible — using the most precise available product subcategory rather than a broad parent category can reduce the scope of publisher exclusions triggered by overly general classifications that encompass more restricted product types than the campaign's actual advertised product warrants. |
| 68 | Targeting | placement ID package (exclude) | A filter that blocks ad delivery on specific individual ad slots whose placement IDs have been explicitly blacklisted in an exclusion package applied to the campaign. A placement ID exclusion package is a curated list of individual ad unit identifiers — unique IDs assigned to specific ad slots within apps or sites — and when a bid request originates from any placement present on that blacklist, it is filtered out before bidding regardless of how well it matches all other targeting criteria. | Review all placement ID exclusion packages currently applied to the campaign — including those inherited from account or advertiser level — to assess the total number of blacklisted placement IDs and their cumulative impact on available inventory. | Regularly audit all active placement ID exclusion packages to remove entries that are outdated, based on stale performance data, or no longer strategically justified — keeping placement exclusion lists lean and current prevents the gradual accumulation of unnecessary inventory restrictions that silently constrain delivery over time. |
| 69 | Targeting | device connection type (supported) | A filter that restricts ad delivery to traffic originating from devices using specific connection types that have been defined as supported in the campaign's targeting settings — such as Wi-Fi, mobile data (2G, 3G, 4G, 5G), or ethernet. When a bid request carries a connection type signal that does not match any of the campaign's allowed connection types, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the campaign's connection type targeting configuration to confirm the supported connection types are intentional and aligned with the campaign's creative format requirements and audience context strategy. | Review the campaign's connection type targeting configuration to confirm the supported connection types are intentional and aligned with the campaign's creative format requirements and audience context strategy. |
| 70 | Targeting | gender | A filter that restricts ad delivery to traffic associated with users who match specific gender segments defined in the campaign's targeting settings. When a bid request carries user gender data that does not match any of the campaign's allowed gender segments, it is filtered out before bidding — ensuring the ad is served only to audiences within the intended gender demographic. | Review the gender segment inclusion list to confirm the selected segments are aligned with the campaign's audience strategy and that the targeting is intentional rather than a default setting carried over from a campaign template. | Where gender signal coverage is low across the campaign's active exchanges, evaluate whether accepting traffic with undeclared gender data is appropriate — particularly for campaigns where gender targeting is a preference rather than a strict brand requirement, as including gender-unknown traffic can meaningfully recover delivery volume without genuine demographic risk. |
| 71 | Filtering | Banner JavaScript is not supported | A filter that blocks ad delivery when the campaign's banner creative requires JavaScript to render correctly but the publisher's ad slot or exchange does not declare support for JavaScript execution in their serving environment. JavaScript is commonly used in banner creatives to enable dynamic content, interactive elements, third-party tracking, and rich media functionality — and when the publisher's environment cannot execute JavaScript, the bid request is filtered out before bidding to prevent broken creative rendering or failed tracking. | Identify which exchanges and publishers are generating the highest volume of JavaScript filtering to determine where JavaScript support gaps are most concentrated across the active supply mix. | Always maintain static image fallback creatives alongside JavaScript-dependent HTML5 banner versions — ensuring delivery continuity across the full range of available inventory, including environments where JavaScript cannot be executed, without sacrificing creative quality on publishers that fully support it. |
| 72 | Targeting | churned operator | A filter that restricts or blocks ad delivery based on whether the user has been identified as a churned subscriber of a specific mobile network operator — meaning a user who was previously a subscriber of the targeted operator but has since switched to a different carrier. This targeting layer allows campaigns to either include churned users as a specific re-engagement audience or exclude them to concentrate delivery on current active subscribers only. When a bid request's churned operator signal does not align with the campaign's configured targeting setting, it is filtered out before bidding. | Review the campaign's churned operator targeting configuration to confirm the inclusion or exclusion setting is intentional and aligned with the campaign's audience strategy — whether the goal is current subscriber concentration or churned user re-engagement. | Where churned operator targeting is used for win-back campaigns, validate that the churned subscriber audience identified through available signal data is sufficiently large and accurately defined to support the campaign's delivery and performance targets — if the identifiable churned audience is too small, consider supplementing with broader competitor operator targeting as a proxy for potential win-back candidates. |
| 73 | Filtering | Native ad asset is invalid | A filter that blocks ad delivery when one or more of the campaign's native ad assets — such as the title, description, image, logo, or call-to-action — do not meet the specifications declared by the publisher's native ad slot in the bid request. Native ads are assembled dynamically from individual creative components that must conform to the publisher's declared asset requirements in terms of dimensions, file size, character count, or format — and when any required asset fails to meet those specifications, the bid request is filtered out before bidding to prevent broken or incorrectly rendered native ad units. | Identify which exchanges and publishers are generating the highest volume of native asset invalidity filtering to determine where asset specification mismatches are most concentrated across the active supply mix. | Ensure native creative assets are produced and configured to meet the broadest possible range of publisher specifications — using industry-standard recommended dimensions and character counts as the baseline reduces invalidity filtering across the majority of the available native inventory pool. |
| 74 | Targeting | SIM amount | A filter that restricts ad delivery based on the number of SIM cards present or active in the user's device — such as single SIM, dual SIM, or multi SIM configurations. When a bid request carries a SIM amount signal that does not match the campaign's configured targeting setting, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the campaign's SIM amount targeting configuration to confirm the allowed SIM count setting is intentional and aligned with the campaign's network audience strategy and operator targeting objectives. | In markets with high dual SIM adoption, carefully evaluate whether single SIM only targeting is creating more delivery restriction than the campaign's strategy genuinely requires — the single SIM audience may represent a significantly smaller share of total available traffic than assumed, warranting a reconsideration of the SIM amount restriction relative to overall delivery scale requirements. |
| 75 | Doubleclick | excluded creative | A filter that blocks ad delivery when the campaign's specific creative has been explicitly excluded by the publisher through Google's Doubleclick ad serving platform. Unlike category or domain-level exclusions that block broad groups of advertisers, this exclusion operates at the individual creative level — meaning the publisher has identified and blacklisted a specific creative asset by its declared Doubleclick creative ID, preventing that particular ad from serving on their inventory regardless of the advertiser, campaign, or targeting configuration it is associated with. | Identify which publishers and exchanges are generating the highest volume of Doubleclick creative exclusion filtering to determine where the creative-level blocks are most concentrated and impactful across the active supply mix. | Where the creative exclusion is driven by a content policy violation or quality flag, identify the specific issue that triggered the exclusion and update or replace the creative to address the concern — submitting a revised creative for review is typically required before delivery can resume on publishers that have applied the exclusion through Doubleclick's ad quality system. |
| 76 | Targeting | device connection type | A filter that restricts ad delivery to traffic originating from devices using specific connection types defined in the campaign's targeting settings — such as Wi-Fi, mobile data (2G, 3G, 4G, 5G), or ethernet. When a bid request carries a connection type signal that does not match any of the campaign's allowed connection types, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the campaign's connection type targeting configuration to confirm the allowed types are intentional and aligned with the campaign's creative format requirements and audience context strategy. | Where connection type targeting is driven by creative format performance requirements — such as avoiding slow-loading video on 2G or 3G connections — evaluate whether excluding only the lowest bandwidth connection types rather than applying broad connectivity restrictions could achieve the same quality objective with less aggressive inventory limitation. |
| 77 | Filtering | no consent for tracking (GDPR) | A filter that blocks ad delivery when the user associated with a bid request has not granted the consent required for ad tracking and personalisation under the EU General Data Protection Regulation (GDPR). GDPR requires that users in applicable jurisdictions provide informed, explicit consent before their personal data can be collected and processed for advertising purposes — and when a bid request carries a consent signal indicating that the required tracking consent has not been obtained, the campaign's bid is filtered out before submission to ensure compliance with applicable data protection obligations. | ||
|
78 |
Targeting | Video Linear/In Stream placement | A filter that restricts ad delivery to video inventory classified as linear or in-stream placements — ads that appear within a dedicated video player as part of a sequential content and advertising experience, playing before (pre-roll), during (mid-roll), or after (post-roll) the primary video content. When a bid request originates from a video placement that is not classified as linear or in-stream — such as outstream, in-banner, or in-feed video formats — it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review the campaign's video placement type configuration to confirm that linear or in-stream targeting is intentional and strategically aligned with the campaign's creative format, KPI objectives, and content environment requirements. | Where in-stream only targeting is significantly constraining delivery, evaluate whether high-quality outstream placements — such as in-article video in premium editorial environments — could serve as supplementary inventory sources that deliver comparable audience engagement and viewability performance to in-stream without the supply scarcity constraints. |
|
79 |
Targeting | behavioural audience (exclude) | A filter that blocks ad delivery to users who have been classified within specific behavioural audience segments that have been explicitly blacklisted in the campaign's targeting settings. Behavioural audience exclusions are built from observed user activity signals — such as browsing history, app usage patterns, content consumption behaviour, or past purchase activity — and when a bid request is associated with a user whose behavioural profile matches any excluded segment, it is filtered out before bidding regardless of how well it aligns with all other targeting criteria. | Review all behavioural audience exclusions currently applied to the campaign to confirm each excluded segment is intentional, accurately defined, and strategically justified for the campaign's current audience objectives. | Periodically audit all active behavioural audience exclusions to confirm each remains strategically justified — removing exclusions based on outdated behavioural data, stale performance insights, or audience characteristics that are no longer relevant to the campaign's current objectives. |
|
80 |
Filtering | Native ad is not SSL compliant | A filter that blocks ad delivery when the campaign's native ad creative contains assets or tracking components that are served over an insecure HTTP connection rather than the encrypted HTTPS protocol required by the publisher's serving environment. SSL (Secure Sockets Layer) compliance requires that all creative assets — including images, logos, tracking pixels, click URLs, and impression trackers — are served exclusively over HTTPS. When any component of the native ad creative fails to meet the publisher's SSL compliance requirement, the bid request is filtered out before bidding to prevent security warnings, mixed content errors, or blocked asset loading on the publisher's secure page environment. | Audit all asset URLs within the campaign's active native creative — including images, logos, call-to-action URLs, impression trackers, and click tracking tags — to identify any components referencing HTTP rather than HTTPS endpoints. | Update all HTTP asset URLs within the native creative to their HTTPS equivalents immediately — ensuring every creative component including images, logos, trackers, and click URLs references a secure endpoint resolves SSL compliance filtering across all publishers enforcing HTTPS requirements. |
|
81 |
Filtering | Audio ad is too long | A filter that blocks ad delivery when the campaign's audio ad creative runtime exceeds the maximum audio ad duration permitted by the publisher's audio placement or exchange declared in the bid request. Publishers and audio streaming platforms define the maximum length of audio ads their placements are configured to accommodate — such as 15 or 30 seconds for standard audio ad breaks — and when the campaign's audio creative is longer than that declared limit, the bid request is filtered out before bidding to prevent truncation, incomplete delivery, or a disrupted listening experience for the user. | Review the runtime of all active audio creatives on the campaign and compare them against the most commonly declared maximum duration thresholds across the target audio exchanges and publisher mix.Review the runtime of all active audio creatives on the campaign and compare them against the most commonly declared maximum duration thresholds across the target audio exchanges and publisher mix. | Produce and activate multiple audio creative versions of varying lengths — such as 15-second and 30-second cuts alongside the full-length version — ensuring the campaign can compete for the broadest possible range of audio inventory while maintaining message effectiveness across different placement duration contexts. |
|
82 |
Filtering | Audio ad file type is not supported | A filter that blocks ad delivery when the audio creative's file format is not supported by the publisher's audio placement or exchange receiving the bid request. Publishers and audio platforms declare the audio file types they are technically capable of rendering — such as MP3, AAC, OGG, or WAV — and when the campaign's active audio creative is encoded in a format outside that declared compatibility list, the bid request is filtered out before bidding to prevent playback failures or silent ad slots that disrupt the listener experience. | Review the audio file formats currently active on the campaign and compare them against the most commonly declared supported formats across the target audio exchange and publisher mix. | Always ensure the audio creative is available in MP3 format as the primary file type — MP3 is the most universally accepted audio format across the majority of programmatic audio exchanges, streaming platforms, and podcast environments and should be the baseline creative asset for all audio campaigns. |
|
83 |
Filtering | Audio ad companion is not supported | A filter that blocks ad delivery when the campaign's audio ad includes a companion banner — a visual display ad served alongside the audio creative to reinforce the brand message with a visual component — but the publisher's audio placement or exchange does not declare support for companion ads in their serving environment. Companion banners are secondary visual creative assets that appear on screen while the audio ad plays, providing a clickable visual touchpoint alongside the audio experience. When the publisher's audio slot cannot accommodate a companion banner that the campaign requires, the bid request is filtered out before bidding. | Review the campaign's companion banner configuration to confirm whether companion support is declared as a mandatory requirement or an optional enhancement — determine whether the campaign is set to only bid on companion-capable inventory or whether it can serve audio-only without the companion. | Where companion banner support is not critical to the campaign's core audio delivery objectives, configure the campaign to serve audio ads without requiring companion support — allowing delivery across the full audio inventory pool including non-companion environments significantly expands eligible supply and reduces companion-driven filtering. |
|
84 |
Filtering | Native video ad is too long | A filter that blocks ad delivery when the campaign's native video ad creative runtime exceeds the maximum video duration permitted by the publisher's native video placement or exchange declared in the bid request. Native video ads are video creatives served within a native ad unit — appearing in-feed, in-article, or within other native content environments — and publishers define the maximum length of native video ads their placements are configured to accommodate. When the campaign's native video creative exceeds that declared limit, the bid request is filtered out before bidding to prevent truncation, incomplete delivery, or a disrupted content experience within the native environment. | Review the runtime of all active native video creatives on the campaign and compare them against the most commonly declared maximum duration thresholds across the target native exchanges and publisher mix. | Produce and activate multiple native video creative versions of varying lengths — such as 6-second, 15-second, and 30-second cuts alongside longer brand storytelling versions — ensuring the campaign can compete for the broadest possible range of native video inventory while maintaining message effectiveness across different placement duration contexts. |