Find ads promoting products that are sold out
The problem and the outcome
The shop knows the stock, the ad platform knows the spend, and nobody owns the space between. An ad can keep paying for a product that cannot be bought. The outcome of this workflow is a list of advertised products whose stock was zero while the ad spent, each with the date the data was checked and the join that connects the two, so a person or an agent can decide what to do with the ad.
A concrete example
What is in the data
A leather phone case was out of stock from 14 to 29 July 2026, and one campaign kept spending on it across those sixteen days: DKK 5,630 for 1,599 clicks and no conversion. The shop's own marketing rules say to pause ads the day stock reaches zero.
What the example claims, and does not
The situation is in the data and is checked there. The page does not publish a score for what a scan of it finds, and reading an export reveals a historical mismatch, not a live one.
Detection, then execution
- Identify the advertised productThe ad platform names a product; the catalogue may spell it differently. The map says which join connects them and how far to trust it.
- Verify the stock matchStock on hand for that product, in the system that holds it, by the key the map gives. An ambiguous match is reported, not guessed.
- Show when the data was checkedThe dates of the exports, or the time of the read. A mismatch in last month’s export is last month’s.
- Propose the ad actionPause the ad set, with the product, the stock figure and the spend behind it. A proposal, written down.
- Apply approvalYour policy for that operation decides: ask first, or allowed. The agent acts in the ad platform with its own access.
- Confirm the resultRead the ad’s state back from the ad platform, then record the outcome in Maplith.
Who does what
What Maplith supplies
The map: where stock and spend live, the tested joins between the product in each, the marketing rules read from your documents, and the record of what was done.
What the agent does
Reads stock and spend in your systems, compares them by the keys the map gives, proposes the action and, when allowed, carries it out in the ad platform.
Where a person decides
Whether an ad is paused, when the policy asks first; every ambiguous product match; and the rule itself.
Routine action versus exception
| Situation | What happens | Who decides |
|---|---|---|
| Stock zero, ad spending, product matched through a tested join | The agent proposes pausing the ad set, with the evidence. | A person, or the policy if you have allowed it. |
| The product in the ad does not match the catalogue cleanly | The agent reports the ambiguity instead of pausing anything. | A person. |
| The exports are older than the ad’s current state | The agent says when the data was checked; it does not claim the ad is running now. | A person, who reads the ad platform. |
Prerequisites
| Part | Why |
|---|---|
| Stock and ad platform data, as exports or a connection | Both sides of the comparison, with a product key in each. |
| Your marketing rules, as the document your team uses | The rule that says when to pause is yours, not Maplith’s. |
| An agent with access to the ad platform | Pausing happens there, with your agent’s own access. |
| An approval policy for the pause operation | Ask first, or allowed, per operation. |
Questions people ask
Does Maplith pause the ad?
No. Your agent does, in the ad platform, with its own access, after the approval your policy requires. Maplith supplies the context and keeps the record.
Can it watch stock continuously?
That is a live rule, checked after a scan finishes and, for a connected system, between scans.
Is there a guide?
Not yet. A tested stock-versus-ads guide follows once a setup has been run end to end. Until then the worked example is the reference.
See the worked example
The e-commerce page shows the same situation with the pieces the agent uses, on the exports of a fictional web shop.