A pixel privacy review should test what the integration does when processing permissions change, not just whether a banner appears. Write the expected behaviour for each configured purpose, exercise the transitions and compare actual requests with that record.
Appnary, in the Shopify technology catalogue observed on October 3, 2026, describes centralized pixel connections. Its listing does not establish a merchant's privacy configuration or the behaviour of every connected destination. The following is a technical evaluation workflow, not a finding that Appnary has a defect or a determination of legal compliance.
Establish the configured permission states
Ask the store owner which purposes are configured and which integrations belong to each one. Analytics and marketing should not be combined into an undocumented all-or-nothing switch simply because that makes the test shorter.
Record the storefront, region settings and test browser state. Existing cookies and earlier choices can change what a returning visitor sees, so a new session and a returning session deserve separate cases.
Use your organization's approved privacy requirements to define the expected result. The technical reviewer should verify that implementation against the requirement rather than inventing the policy during a browser session.
Read the platform signal
Shopify's Customer Privacy API exposes checks for purpose-specific processing permissions and mechanisms for registering consent. Its permission decisions consider merchant configuration, location and the visitor's choice. A visible banner alone does not establish the resulting permission state.
For an authorized implementation review, record the relevant platform signal alongside the integration's behaviour. If the API fails to load or a state cannot be determined, preserve that uncertainty instead of reporting the visitor as having granted permission.
Do not create a parallel consent flag that silently disagrees with the platform. If a custom integration needs an adapter, document how its states correspond to the source signal.
Exercise changes during one visit
Start with the configured initial state and perform a harmless product-view action. Then change the relevant preference through the supported interface and repeat the action. Inspect requests using the destination's diagnostics and the browser's network tools.
Include a later change of mind where the interface supports it. Check whether subsequent activity follows the new preference and whether the UI accurately reflects the saved choice after navigation.
Keep the distinction between past processing and future processing explicit. Stopping new requests does not, by itself, prove that an external service deleted previously received data. That separate lifecycle needs its own documented procedure.
Explain missing events accurately
A report should distinguish processing not permitted, request attempted, destination accepted and event unavailable for another reason. Otherwise, a marketing team may try to repair an intentional absence by installing an extra unrestricted snippet.
Review the conversion event mapping guide alongside this state matrix. Event meaning and permission state jointly determine what a valid observation looks like.
Retain configuration version, test date and redacted evidence. Repeat the bounded checks after changing a banner, pixel app or custom integration, because a successful earlier review does not establish the behaviour of a later configuration.
