How to Read Your Evidence File

The evidence file is the record of a visit to your website on a stated date. It shows what the visitor's browser sent and received while your pages loaded, and which outside companies received data. This guide explains each part in plain words, so you, your web team, or your counsel can check it against your own site.

What is in the evidence file?

Most evidence files have four parts:

• The network record. A list of the requests the browser made during the visit, in order, with where each one went, when it went, and what it carried.
• Screenshots. Pictures of the pages as the browser showed them during the visit, including any cookie banner.
• Timestamps. The date and time of the visit, of each screenshot, and of each request.
• SHA-256 values. Fingerprints of the files, so anyone can confirm that a file has not changed since it was preserved.

Your case portal shows these on the evidence page, and the exhibits that came with the letter are taken from the same record.

How do I read the network record?

When a browser opens a web page, it asks your server for the page, then follows the page's instructions to load images, fonts, and code. Some of that code belongs to other companies, such as Meta, Google, TikTok, or a session replay vendor. That code makes the browser send requests to those companies' servers.

The network record lists those requests. For each one you will usually see:

• The address. The server the request went to, such as www.facebook.com/tr for the Meta Pixel or www.google-analytics.com/g/collect for Google Analytics, with the full address and its parameters.
• The method. Usually GET or POST. A POST request also carries a body with more data.
• The time the browser sent it.
• The content. What the request carried: which page was open, its title, the event (a page view, a click, a form step), and identifiers such as cookie values.
• The response. What the other company's server sent back, such as a status code or a new cookie.

Read each request for three things:

1. Where it went. The host name tells you which company received it.
2. What it carried. Look for the page address and title, the event name, and identifiers. In a Meta Pixel request, ev is the event and dl is the address of the page that was open. In a Google Analytics request, en is the event name, dl is the page address, and dt is the page title.
3. When it went. Compare the time with the screenshots. A request sent before the visitor made any choice on a cookie banner, or after the banner's own "Reject" control was used, is the heart of most letters.

Where the portal offers a copy of the network record to download, it is a redacted copy: some request and response bodies are left out, and the complete record is preserved. Your web team can load the copy into the Network panel built into Chrome or Firefox and read it the same way they read live traffic.

What do the screenshots show?

The screenshots show what a visitor saw: the page, whether a cookie banner appeared, what choices it offered, and what the page looked like after a choice was made. Each one carries the time it was taken. Read them alongside the network record: the screenshot tells you what the banner said, and the requests around the same time tell you what the site did.

Some records have a second part, made after the banner's own "Reject all" or "Necessary only" control was used. That part shows what the site sent after a refusal.

How do I read the timestamps?

Every request and screenshot carries a date and time. Times in the exhibits are in UTC (Coordinated Universal Time) unless the page says otherwise. New York is four hours behind UTC in summer and five hours behind in winter, so a request at 15:02 UTC on an October day was sent at 11:02 a.m. Eastern.

The order matters more than the clock. A request that comes before the banner screenshot was sent before the visitor could choose anything.

What is a SHA-256 value?

A SHA-256 value is a 64-character fingerprint calculated from a file's exact contents. Change a single character in the file and the value changes completely. Where they were recorded, the evidence page lists the SHA-256 values of the evidence record and of the package delivered with the letter.

You can check a file yourself:

• Mac: open Terminal and run shasum -a 256 followed by a space and the file (drag the file into the window to fill in its location).
• Windows: open PowerShell and run Get-FileHash followed by a space, the file's location, and -Algorithm SHA256.

If the value printed matches the value on the evidence page, the file is the same file that was preserved.

How can I check the record against my own site?

Your own systems hold records of the same visit date:

• Tag manager history. Google Tag Manager keeps a version history. The version live on the visit date shows which tags were published and what triggered them.
• Consent platform settings. The configuration in force on that date shows whether tags were blocked until consent and what "Reject" was set to do.
• Server-side containers and logs. If your site sends tag data to a server you run, its configuration and logs show where that data was forwarded.
• Today's site. Run the five-minute Reject button test to see how the site behaves now. If you have changed the site since the visit, keep a record of what changed and when; a change today does not alter what was recorded on the visit date.

Preserve these records. Do not delete tag manager versions, consent logs, or server logs while a matter is open.

Who can help?

Your web developer can read the network record with you in an hour. Your own attorney can review the evidence and the letter together, and you can invite counsel into the portal so they see the same materials. For questions about the portal or your case, call or text (888) 649-4500.