Documenting a Cloaked Funnel for a Compliance Report

What makes funnel evidence credible to a platform or regulator?

Credible funnel evidence is reproducible, time-bound, and tied to a specific request. You need enough context for someone else to replay the same path or at least verify that your capture was not staged. That means a timestamp, the origin IP or proxy egress, device details, the request URL, full response headers, and an untouched visual record of the page as rendered.

A screenshot alone rarely carries weight because it does not show how the server decided what to serve. A PDF export is weaker still. It can flatten redirects, strip headers, and hide the split-second clues that show a cloaked response happened in the first place. If the operator says you fabricated the page, the fastest answer is a packet of raw evidence, not a narrative.

Platforms and regulators usually care about two things: whether the claim is specific and whether the evidence is traceable. The FTC’s endorsement guides matter here because they force you to separate what was observed from what was inferred. Meta’s advertising policies matter for the same reason: reviewers want to know whether the creative, landing page, or routing violated a rule, not whether you have a strong suspicion.

One short rule: capture the page like a forensic analyst, not like a marketer.

That does not mean you need a court-grade lab for every report. It means you should be able to answer basic questions: What did the server return? Which request got that response? Was the page fetched over mobile Safari or desktop Chrome? Was the result stable over 2 or 3 attempts, or did it only happen once?

Which metadata must accompany every capture?

Every capture should carry five metadata blocks: time, network, device, request, and collector. Time means the exact date and local clock time, ideally with timezone and seconds. Network means source IP, ASN if you have it, VPN or proxy status, and any geo service result you used. Device means browser version, OS version, viewport, and user agent. Request means URL, method, cookies if relevant, and the sequence of redirects. Collector means the tool or person that gathered the evidence.

If you omit one of those blocks, the report becomes easier to dispute. A capture from 09:14 without timezone is less useful than a capture from 09:14:33 UTC-3. A mobile screenshot without device model can still be questioned. A response dump with no request URL is just a blob of text.

For practical work, this is the minimum bundle I would expect:

• Exact timestamp in UTC and local time
• Source IP or proxy egress IP
• Country or region reported by the testing path
• Browser name and version
• Operating system and version
• Viewport or screen size
• Request URL and redirect chain
• Full response headers
• Raw HTML or saved page artifact
• Unedited screenshots with visible URL bar where possible

The point is not to collect trivia. The point is to let a reviewer distinguish a device-specific serve from a generic page. If the ad landed on a different offer page for iPhone Safari in California than for desktop Chrome in Texas, the metadata should make that difference obvious without interpretation.

How do you prove the response differed by geo or device?

You prove a geo or device difference by changing one variable at a time and repeating the same request path. Keep the URL, time window, and collector constant. Then vary only the source country, the device class, or the browser profile. If the response changes in a stable way across repeats, you have evidence of routing or personalization.

The strongest proof is paired captures. For example, one request from a U.S. residential connection on iPhone Safari returns the offer page, while a second request from a datacenter IP on desktop Chrome returns a neutral page or a different redirect. If both requests hit the same endpoint at nearly the same time and the server answers differently, that is materially stronger than a single lucky screenshot.

This is also where people overstate what they have. A different page by itself does not prove intent. It may be load balancing, a geofence, an A/B test, or a bot filter. You need to show the pattern across at least 2 or 3 attempts, with the same delta each time. One odd response can be a fluke. A repeatable split is evidence.

Here is the worked shape of it: first capture from a mobile simulator over a residential network returns a pre-lander with a form. Second capture from a desktop machine over the same network returns the same pre-lander. Third capture from a datacenter egress returns a generic interstitial. If the headers, HTML, and screenshots line up, the report can say the funnel varied by source network. If the page also changes when only the user agent changes, that separate finding deserves its own block.

Short version: vary one input, repeat the request, and preserve the deltas.

That method beats a larger archive in most compliance settings. A huge folder of old captures may look thorough, but reviewers usually care more about what happened in this campaign window than what happened 90 days earlier. The current behavior is the question. The archive is support.

What does chain-of-custody mean for web evidence?

Chain-of-custody means you can account for the evidence from capture to storage to delivery without a gap. You do not need a notarized lab report for ordinary compliance work, but you do need a traceable path. Who captured it, when, on what device, where it was saved, whether it was modified, and who received it are the core facts.

The easiest way to protect custody is to treat the first saved file as read-only and never overwrite it. Keep a master folder, a working copy, and a delivery copy. Record hashes for the master files if you can. If your team later questions whether a screenshot was edited, a stable hash plus an unbroken file history answers that faster than a paragraph of explanation.

Document every handoff. If one analyst captures the page and another analyst writes the memo, note both names in the internal log. If a lawyer or network manager asks whether the screenshot was cropped, rotated, or redacted, the answer should be visible in the version history. That is the difference between evidence and a presentation deck.

Chain-of-custody also covers negative findings. If a capture failed because the page timed out or a challenge page blocked the request, log that failure with the same discipline. A failed attempt can matter as much as a successful one because it shows how the funnel behaved under a defined test condition.

How do you preserve a page before it disappears?

You preserve the page in multiple forms at once. Save the visible render, the raw HTML, the response headers, and if possible the full network trace. A single artifact can lie by omission. Four artifacts are harder to dismiss.

Use a browser profile that can export devtools data or a capture tool that stores both the screenshot and the HTTP transaction. If the page is short-lived, capture it immediately after load and again after any redirect settles. If the funnel injects content by script, the HTML snapshot alone may miss the render state. If the landing page is behind a timing gate, the screenshot alone may miss the earlier redirect.

For disappearing pages, the order matters. First preserve the live state. Then collect the network data. Then create the human-readable memo while the session details are fresh. Do not start by summarizing what you think the page meant. That habit destroys the evidentiary value of the underlying capture.

One practical rule applies across tools: the file you submit should not depend on your memory. If an operator deletes the page later, your packet should still show the URL, the headers, the visual state, and the collection time. That is why legal-tech capture workflows are useful even in affiliate and media-buying contexts. They are built to survive dispute.

What formats do platforms and networks actually accept?

Most reviewers accept a compressed bundle with a memo, screenshots, and supporting files. Some want PDF. Some want a ZIP with individual image files and text exports. Some will only work from a ticketing system or an internal escalation form. The exact intake format varies by network, so check the current instructions before you submit.

In practice, the safest package is a PDF narrative plus a ZIP of raw files. The PDF tells the story in order. The ZIP carries the proof. If the reviewer only reads the PDF, the report still works. If they need to inspect the source materials, the raw files are there.

Do not assume that a platform reviewer wants your whole archive. They usually want the shortest path to a defensible conclusion. A tight memo, 3 to 6 labeled screenshots, the headers, and a short attachment list are easier to process than a 200 MB folder dump. The goal is not to impress them with volume.

Per the FTC’s endorsement guides, clarity about what was observed matters more than rhetorical confidence. Per Meta’s advertising policies, the relevant question is whether the page or ad activity crosses a policy line. Per the public pricing and feature descriptions from tools like Similarweb, BuiltWith, or AdSpy, remember that commercial monitoring products can help with discovery, but they do not replace a clean evidentiary packet. Their output is a lead, not a verdict.

The best submission format is the one the recipient already knows how to open. If you can, match the network’s intake pattern and keep the evidence intact underneath it. That cuts friction without weakening the record.

What does a complete report package look like?

A complete package has a front page, a timeline, the capture set, and a short conclusion that stays inside the evidence. It should tell the reviewer what was tested, how it was tested, what was observed, and what can be proven from the materials. Nothing more is required.

A practical folder structure looks like this:

• 00_readme.pdf with scope, dates, and summary
• 01_timeline.csv with capture timestamps and test conditions
• 02_screenshots/ with numbered, unedited images
• 03_headers/ with raw response headers and request notes
• 04_html/ with saved page source or browser archive files
• 05_hashes.txt with file integrity values if available
• 06_notes.txt with collector notes and anomalies

The README should be blunt. State the date range, the source network, the browser, and the exact behavior you observed. If the page only appeared on one device profile, say that. If a redirect chain changed on retry, say that. If a field is uncertain, mark it uncertain instead of smoothing it over.

That last part matters more than people admit. A report that overclaims loses trust fast, especially with compliance teams that already expect sellers to exaggerate. A report that says, for example, “the capture indicates a device-based response split, but the test set is too small to rule out an A/B test” reads as careful, not weak. Precision is the point.

Bottom line: the packet should let someone else reach the same conclusion from the same files.

If you are building this process for a team, standardize the capture template and do not improvise the evidence list every time. The template should force time, network, device, request, and file integrity into the record. That discipline is the whole defense.

Frequently asked questions

What is the minimum evidence set for a cloaked funnel report?

The minimum set is timestamp, source network, device context, request URL, response headers, and unedited screenshots. That combination lets a reviewer verify what was tested and how the server answered. Without those pieces, the capture is easy to dispute.

Do screenshots by themselves prove cloaking?

No. Screenshots show appearance, not routing. A screenshot becomes useful only when it is paired with headers, request context, and a repeatable test path. Otherwise the operator can argue that the image was staged or that the page changed for another reason.

Should I include old archive captures?

Include them only if they support the current finding. Old captures can show pattern, but they do not replace fresh evidence from the campaign window. For compliance work, the recent behavior usually matters more than archive depth.

What file format is safest to submit?

A PDF memo plus a ZIP of raw artifacts is the safest default. The PDF gives the narrative, and the ZIP preserves the technical proof. If the recipient has a different intake format, match it, but keep the raw files unchanged underneath.

Sources

Named rather than linked — verify before relying on any figure below.

• FTC Endorsement Guides
• Meta Advertising Policies
• Similarweb pricing and product pages
• AdSpy published pricing and feature pages