Data Privacy: What We Collect and Why
IP Snare is built to work with the click logs you already produce as a buyer. We don't ask for anything new or sensitive: just the click metadata you'd already pull from your tracker when reconciling a refund.
No revenue figures. No client names. No system access. Ever.
What We Collect
Every click sent to IP Snare carries a small set of metadata fields. Each one serves a specific purpose in classifying the click as billable or non-billable, and in computing how much refund you're owed when it isn't.
Click Identification
These fields let us match, deduplicate, and trace every click that lands in your refund report.
| Field | What It Is | Why We Need It |
|---|---|---|
click_id | Unique identifier for the click | Core reference for tracking and deduplication |
source_click_id | The click ID assigned by the upstream feed | Links the click back to the originating feed so the refund report can show evidence the publisher will recognise |
source_id | Identifier of the feed or traffic source the click came from | Groups traffic by feed so the refund report can be broken down per source |
destination_id | Identifier of the destination the click was bought against | Lets you scope refund reports to a single destination when you operate more than one |
User Signals
These fields help us detect bots, flag suspicious patterns, and verify geographic targeting.
| Field | What It Is | Why We Need It |
|---|---|---|
user_ip | The IP address of the user who clicked | Core signal for bot detection, proxy identification, and geo-validation |
user_agent | The browser and device string of the user | Identifies known bot signatures and headless browsers |
user_country | The country of the user | Validates whether the click matches the expected geographic targeting |
bot_name | The name of the bot if the click was identified as automated (e.g. googlebot, bingbot, chatgpt) | Lets the refund report break bot traffic down by source and exclude legitimate platform crawlers from refund totals |
Job & Timing
These fields let us check whether a click is valid in context — right job, right country, right time, not a duplicate.
| Field | What It Is | Why We Need It |
|---|---|---|
job_id | Identifier of the job listing clicked | Ties the click to a specific job for expired-job and duplicate-click checks |
job_country | The country the job is posted in | Cross-referenced with user_country to flag geographic mismatches |
click_time | Timestamp of when the click occurred | Used for time-based validation, deduplication windows, and trend analysis |
expired_at | Expiry timestamp of the job listing (if applicable) | Determines whether the job was still live at the time of the click |
is_bot | Whether your tracker already flagged this click as a bot (0 or 1) | Lets you pass through your own bot assessment alongside our independent classification, so the report shows where the two agree and where they don't |
final_click | Whether this is the last click in a redirect chain (0 or 1) | Identifies the billable click when traffic passes through multiple hops |
Refund Calculation
These two fields are what turn a list of invalid clicks into a refund amount. They are part of the click payload, not a separate billing integration.
| Field | What It Is | Why We Need It |
|---|---|---|
cpc | The cost-per-click you paid for this individual click | Multiplied by each non-billable click to compute the refund total per feed |
cpc_currency | The currency the CPC is denominated in (e.g. USD, GBP, EUR) | Lets the refund report aggregate credit potential by currency when feeds are priced in more than one |
We never see your contracts, rate cards, or invoices. The CPC arrives one click at a time inside the same payload as the rest of the click metadata, and is used purely to multiply against invalid-click counts.
What We NEVER Collect or Ask For
IP Snare is deliberately designed to work without access to your commercial systems. We will never ask you for:
- Revenue or earnings, your financial data stays in your systems
- Rate cards, contracts, or invoicing access, the per-click
cpcvalue in the click payload is the only pricing input we ever see - Client or advertiser names, we identify partners by ID, not by name
- Campaign budgets or total monthly spend, irrelevant to refund classification
- Bid data or margins, your commercial strategy is yours alone
- Candidate or applicant data, we never see who applied or their personal details
There is nothing commercially sensitive on our platform beyond per-click CPCs you choose to send. No connection to your billing system, no credentials to your CRM, no integration with your invoicing.
Your Reports, Yours Alone
Every report on IP Snare belongs to one buyer:
- You see only your own click data, never another buyer's
- A publisher only sees a refund report when you choose to share it with them, and only that report
- No publisher and no other buyer can browse, search, or aggregate your data
Each refund report is scoped to a single share link. Sending it to a publisher gives them a read-only view of that report and nothing more.
This Is Data You Already Have
When a refund case comes up today, you're the one pulling logs and stitching IPs, timestamps, user agents, and job IDs into something the publisher will read. IP Snare ingests exactly that metadata and turns it into a structured refund report automatically.
No new data exposure. No commercial risk. Just the click logs you already collect, doing the work of building your refund case.
Ready to see it in action? Book a demo and we'll walk you through exactly how your data is handled.