Know which visits were real
Campaigns still pay for check-ins that never happened. PoP sits between the door and whatever you do next: credit the visit, unlock a reward, or gate access — on a result another system can check.
Not an event page. Not a GPS tracker. A verification step for teams that already run activations, loyalty, or field stops.
One weekend, not a theory
A pop-up that billed on check-ins
A drinks brand runs a three-day pop-up. A partner app will reward people who came. The brand is invoiced on check-ins. This is the usual failure — numbers are illustrative.
What the dashboard showed
4,200 check-ins
- Same QR on the poster all weekend
- The code was in group chats by Saturday
- The reward app trusted the export
What the door saw
~800 people
- Staff reused the same code across shifts
- Finance cannot explain the gap
- Rewards still went out against the 4,200
With PoP on that door
A tablet shows a code that expires quickly. Each confirmation is tied to that source and that window. The partner counts verified visits. The reward app asks PoP before it unlocks anything. The invoice follows the door, not the group chat.
How that flow runs ->Why this is a business problem
Check-in numbers lie more often than teams admit
If you pay, report, or unlock something on “someone was there,” a shareable QR or a map pin is already the wrong input. The cost shows up as leaked budget, unusable reports, and a fact no other system can re-check.
You cannot tell a guest from a forwarded code
A poster QR, a PDF ticket, or a “unique” link still travels through chats. The scan still looks valid.
Reward and sampling budgets leak
People who never entered still get the drop, the SKU, or the points — because the trigger was a shareable check-in.
The report looks strong until someone asks what it means
Four thousand check-ins against an 800-person door count is not a rounding error. It is a broken unit of measurement.
Attendance is stuck in one tool
The event SaaS has a guest list. Your CRM, reward, or access product cannot independently ask “was this person there?”
Today’s check-in vs PoP
Most teams already have a check-in. The gap is whether that result can be trusted, reused, and paid against.
| Compared | Typical check-in | What goes wrong | With PoP |
|---|---|---|---|
| What counts as a visit | A scan, a pin, a selfie, or a row in the event tool | Screenshots, GPS spoofing, staff reuse, group-chat codes | A confirmation bound to a live source and a short time window |
| What the business receives | A private list inside one product | You pay and report on a number you cannot re-check elsewhere | A verification result the partner dashboard and another app can both use |
| What happens next | Ops export a CSV and hope the next system trusts it | Rewards, access, and invoices inherit the same error | Credit the campaign, unlock a reward, or gate the next action on the same fact |
How it works
Four steps from the door to a result you can use
PoP V1 starts with a live, short-lived QR at a presence source. Stronger proximity methods come later. The product job stays the same.
Step 1
Partner sets up the action
A campaign or event, a place, a time window, and a check-in surface — usually a live QR on a tablet at the door.
Step 2
The person confirms on site
They scan and confirm. Email is enough. A wallet is optional. The code is short-lived, so a screenshot from yesterday does not count.
Step 3
The partner gets a usable result
Verified visits, not a dump of forwarded scans. That list is what you report, credit, or send downstream.
Step 4
The same fact is used elsewhere
A reward app, an access rule, or campaign ops can check the visit without trusting a spreadsheet from another product.
The partner keeps the campaign. PoP answers whether the visit happened.
Where the proof is used
Step four only matters if you know which system consumes the result. In practice it is one of these:
Campaign reporting
Count only visits that passed the check. That is the number finance and the brand can stand behind.
Rewards and sampling
Your loyalty or partner app asks PoP before it unlocks a gift. No visit, no payout.
Access to the next step
A second event, a drop, a community role — gated on a verified action, not a forwarded code.
Another product, same proof
An integrator calls verify and applies its own rule. The fact is not trapped inside the PoP dashboard.
For business
Run one live action. Pay on verified visits.
A pilot is a real venue or campaign, a check-in at the source, and a downstream use — a report, a reward, or a gate. We help you pick the action and what “good enough” means for that spend.
Campaigns and event check-ins
Count people who actually came — then credit the campaign on that number.
How this looks ->Loyalty visits and gated rewards
Unlock a reward or entry only after a verified visit.
How this looks ->Field stops and route checks
Close a stop when the action happened, not when a pin appeared on a map.
How this looks ->For integration
Put verification under a product you already have
Campaign, challenge, claim, result. Another product calls verify and decides what to unlock. PoP is the proof layer — not the event page, the loyalty wallet, or the ticketing stack.
Discuss a pilot
Tell us the action you need to verify — a pop-up, a loyalty visit, a field stop — and what should happen after it passes. We will map the source, the flow, and the system that consumes the result.