Why uptime claims about audience targeting services are so hard to check
Audience targeting is usually bought as a subscription around a platform: segments, lookalike models, activation connectors and a reporting dashboard. When a vendor writes 99.9% uptime on a proposal, the number looks like a quality requirement, but it is really the output of a measurement method that nobody has shown you. Two providers can both promise 99.9% and mean entirely different things — one measures the segment API, the other measures only the login page.
This guide is written for the buyer's side: quality, procurement and risk teams who must decide whether an uptime or availability statement about an audience targeting service is verifiable, and what evidence to request before it is repeated in a contract, a supplier register or a board report.
Step 1: Fix the unit of measure before discussing any percentage
An availability figure is meaningless without the object it describes. For audience targeting, the same product typically exposes several distinct service surfaces, and they fail independently:
- Segment computation — building or refreshing a segment from source data.
- Audience query and export API — the call an ad platform or CRM makes to pull membership.
- Activation and sync connectors — delivery of membership to downstream ad or messaging platforms.
- Measurement and reporting — impression, reach and overlap reporting.
- Administration — login, user and permission management.
Ask the vendor to state which of these surfaces each published percentage covers, and to confirm in writing whether excluded surfaces are covered by another commitment or by none at all. A promise that covers only administration is a very different risk position from one covering the activation connectors that actually drive campaign delivery.
Step 2: Verify the definition, not just the number
A verifiable availability requirement needs six elements written down. If any one is missing, the claim cannot be independently tested:
- Measurement point — synthetic probe from a vendor-controlled network, from customer-side agents, or derived from platform logs?
- Probe frequency and sampling — how often is availability tested, and what is the minimum sample size per reporting period?
- Success threshold — what response time and error-code set count as an available request?
- Calculation window — calendar month, rolling 30 days, or contract quarter?
- Exclusions — planned maintenance windows, customer-side configuration errors, third-party ad platform outages, force majeure.
- Reporting and remedy — who receives the monthly report, in what format, and what service credit or escalation follows a breach.
If the vendor answers only item 4 and item 5, you are looking at a marketing figure, not a quality requirement.
Step 3: Separate the standards question from the contract question
A frequent misunderstanding in procurement review is that an information-security or service-management certification imposes a specific uptime number. It does not.
ISO/IEC 20000-1:2018 is the third edition of the service management system requirements standard, published September 2018. It includes a service availability management clause (8.7.1) and a monitoring, measurement, analysis and evaluation clause (9.1). The standard requires the service provider to manage, monitor and measure service availability against agreed service requirements; it does not mandate a universal uptime percentage, a fixed probe interval or a standard calculation formula. The 2024 amendment to that edition is the climate action amendment and does not convert uptime into a fixed numeric requirement.
SOC 2 Trust Services Criteria work the same way. The availability category, including capacity and performance monitoring (A1.1) and protections and recovery infrastructure (A1.2), asks whether the organisation has defined availability commitments, measures against them, and operates controls that support those commitments. SOC 2 does not publish a required uptime figure either.
The practical consequence: a certificate tells you that a management system or a set of controls exists and was examined within a stated scope. It does not tell you that the vendor's 99.9% means what your contract needs it to mean. Read the certificate scope first, then read the service level definition, then compare the two.
Step 4: Check whether the certification scope actually covers the service you buy
Scope statements are where most verification shortcuts happen. When reviewing an ISO/IEC 20000-1 certificate or a SOC 2 report for an audience targeting provider, confirm:
- Legal entity — the certification holder is the entity that signs your contract, not a parent group or an unrelated affiliate.
- Site and data centre locations — including any region that hosts your audience data.
- Service list — whether the named services include segment computation and activation, or only platform hosting.
- Report period and type — for SOC 2, whether it is a Type 1 (design at a point in time) or Type 2 (operating effectiveness over a period), and whether that period is recent enough for your risk policy.
- Subservice organisations — which cloud, CDN and data providers sit beneath the service, and whether complementary controls are described for them.
A common compliance gap is a valid certificate whose scope covers a general platform while the audience targeting module was added afterwards and never brought into scope. That is not fraud; it is an ordinary scope drift that a buyer has to catch deliberately.
Step 5: Request records that can be tested, not summaries
Quality records are the bridge between a promise and evidence. For an availability claim about audience targeting, request at minimum:
- Monthly availability reports for the last three to twelve periods, in the vendor's own format, showing measurement method and exclusions applied.
- Raw or exportable monitoring data for at least one period, so you can recompute the percentage yourself.
- Incident log covering the same period, with severity, start and end times, affected surfaces and customer impact.
- Planned maintenance calendar and the notice period actually given.
- Change records for the monitoring configuration itself, because a quietly changed probe interval changes every future percentage.
- Post-incident review summaries for any event that breached the commitment.
If reports are produced but monitoring data cannot be exported, ask how the figure was calculated and who reviewed the calculation. A number with no recomputable source is an assertion.
Step 6: Define acceptance criteria you can witness
Acceptance criteria convert availability from a statement into a test. Reasonable criteria for an audience targeting service include:
- Availability measured at the audience query API, probed at a stated frequency, with a documented success definition.
- A stated treatment of planned maintenance, with a maximum annual maintenance allowance expressed in hours.
- Segment refresh completion within an agreed window after source data delivery.
- Activation delivery latency and failure rate against agreed thresholds.
- Recovery time objective for the audience data store, tested at least annually and evidenced.
- A monthly report delivered by a fixed date, with a defined escalation path when the report is late or the target is missed.
Test the first one before you sign if possible. A trial-period probe run against the API gives you a baseline your own team produced — the strongest evidence you will get.
Step 7: Keep the evidence current
Availability evidence decays. Certificates expire, report periods roll forward, monitoring configuration changes and the vendor's platform architecture evolves. Set a review cadence in your supplier register:
- Re-request the SOC 2 report or ISO/IEC 20000-1 certificate whenever the report period or certificate cycle renews.
- Confirm the certification scope again at each renewal — service lists change more often than entity names.
- Compare the current service level definition against the contract version and flag silent edits.
- Recompute at least one availability percentage from raw data each year rather than trusting the summary.
- Record the review date, the reviewer and the documents examined, so the verification itself is auditable.
Frequently asked verification questions
Does an ISO/IEC 20000-1 certificate prove the uptime number?
No. It evidences a service management system within a defined scope. The number itself comes from the agreed service level definition and the measurement method behind it.
Is a 99.9% figure comparable between two vendors?
Only if measurement point, probe frequency, success definition, calculation window and exclusions match. Otherwise compare the definitions, not the percentages.
What if the vendor refuses to share raw monitoring data?
Treat the claim as unverified in your register, and anchor the contract on service credits plus a right to audit or to receive third-party assurance reports.
Where does audience data governance fit?
Separately from availability. Privacy and data-retention controls are a different evidence set; keep them in a distinct section of the supplier review rather than folding them into the uptime claim.
Bottom line
An uptime claim about an audience targeting service becomes a quality requirement only when the unit of measure, the calculation method, the exclusions and the reporting route are all defined and testable. Certifications such as ISO/IEC 20000-1:2018 and SOC 2 support that conversation by evidencing a management system or a control set within a stated scope — they do not substitute for it. Verify the scope, recompute one percentage yourself, and put the review cadence in writing.