Guide
Validate data collection
Generate representative traffic and confirm that it appears in the intended SiteWall project.
Last reviewed September 12, 2026
Validation proves that an installed website can send useful observations to the intended SiteWall project. It also establishes the limits of the first dataset: SiteWall can only describe behavior present in the pages, user states, consent choices, and feature paths that received traffic.
Generate representative traffic
- 1.
Start with an identifiable test window
Record the start time, browser, website environment, and tester. This gives you a concrete period to compare with activity in SiteWall.
- 2.
Visit important pages
Open the pages that represent the initial scope, such as the home page, sign-in, account area, form, checkout, or other business-critical routes.
- 3.
Exercise conditional behavior
Trigger the actions that load third-party services: make consent choices, open chat, play media, submit a test form, sign in, or progress through a test transaction where authorized.
- 4.
Repeat a meaningful alternate state
Test at least one different condition—such as another consent choice, authenticated state, page, or feature path—to reveal activity that is not present in the first journey.
Confirm the records in SiteWall
- 1.
Return to the same project
Recheck the project selector and confirm that the selected project matches the tested hostname. Allow normal processing to complete, then refresh the relevant views.
- 2.
Open Providers
Confirm that recognizable third-party services from the test appear and that their activity time is consistent with the validation window.
- 3.
Open Inventory
Confirm that individual resources associated with those providers appear. Compare names and hosts with services you expected the tested pages to load.
- 4.
Open Sessions
Find a session from the test period and confirm that its page and available activity context correspond to a journey you performed.
- 5.
Open Exposure Map
Confirm that SiteWall connects the website to at least one expected provider and resource. Use the map to check the observed path rather than treating a count alone as validation.
If expected data does not appear
Use the following table to understand how each area supports the task.
| Check | What to confirm |
|---|---|
| Project | The copied installation code and the open SiteWall view belong to the same project. |
| Domain and route | The exact hostname and page tested are included in the deployment. |
| Initialization | The code is present, executes, and is not blocked by a browser error. |
| CSP and consent | Security and consent rules permit SiteWall to load in the state you tested. |
| Journey | The test actually triggered the conditional resource or feature. |
| Filters and timing | Processing completed and no search, status, category, or time filter hides the record. |
Record the validation result
- 1.
Document the tested scope
List the hostname, pages, journeys, user and consent states, browser, test time, and tester.
- 2.
Record the matching SiteWall views
Note which providers, resources, sessions, and relationships confirmed collection. Link the source records when your operating process supports it.
- 3.
Record known gaps
List pages, regions, devices, roles, consent states, or conditional features not yet exercised. Treat them as unvalidated—not as evidence of absence.