Customer Data
Part of Experimentation platforms
Reviewing privacy and consent controls for testing software
Check cookies, identifiers, event flows, refusal and withdrawal behaviour when assessing testing software for an Australian team.
Review testing software by tracing what it collects before, during and after a visitor's tracking choice. Identify the cookies or local storage, identifiers, targeting attributes and events involved; when data leaves the device; and what refusal or withdrawal changes. A consent banner alone does not answer those questions.
Map the data flow
For a proposed experiment, follow data from the site or app to the vendor, reports and exports. List the assignment identifier, targeting attributes, exposure records and outcome events. Check whether URLs, form values or event metadata could carry personal information, and omit fields the experiment does not need.
In Australia, privacy duties depend on the organisation and information involved. For entities covered by the Australian Privacy Principles, collection notice, later use or disclosure, and some overseas disclosures may need assessment.
The OAIC's APP 5 guidance discusses notification of the collection of personal information and the reasonable steps an APP entity must take. The organisation's privacy owner should assess the actual arrangement.
Check the first page load
Examine three states: no choice yet, refusal and consent. For each, establish whether the snippet or SDK runs, what is stored locally, what is sent to the vendor and which page variation appears.
Optimizely Web documents several consent implementation options. Disabling the experiment until consent can leave a visitor on the original page, preventing an unconsented first landing-page view from entering that test.
Optimizely Web documents holdEvents and sendEvents as options for gating on consent. These options have different privacy and measurement effects and must be assessed against the team's requirements.
Consent Implementation Options in Optimizely Web
- Option: Disable experiment until consent
- Prevents unconsented landing page view; visitor remains on original page
- Option: Use holdEvents and sendEvents
- Gates event sending based on consent; affects privacy and measurement differently
Inspect identifiers and attributes
A feature testing SDK may use a context key and attributes for targeting or consistent assignment. Check whether the key identifies a person directly, is reused elsewhere or can be linked back to one. Remove unnecessary attributes at the source.
LaunchDarkly documents private attributes that remain usable for targeting while being omitted from event data. Its context key and kind cannot be marked private. This control does not make the whole context anonymous; review the proposed SDK and configuration.
Private Attributes in LaunchDarkly SDK
- ProsPrivate attributes can be used for targeting without appearing in event data; reduces privacy risk
- ConsContext key and kind cannot be marked private; does not anonymise the whole context; requires review of SDK and configuration
Plan for refusal and withdrawal
Walk through a hypothetical withdrawal. What stops immediately? What happens to queued events, earlier assignments and later exports?
Who handles a deletion or correction request, and how would they locate the record? Stopping new collection does not itself remove data collected earlier.
Keep a decision record covering approved fields, consent behaviour, notice ownership, any overseas-data assessment, retention and the configuration evidence. Resolve unknowns before launching an experiment that uses personal information.
