A map of what was visible.
Activated sources, observed surfaces, consent gaps, collection interruptions and paths outside the integration. An unavailable surface stays unavailable.
SHOPIFY · DESIGN PARTNERS
Bring one automation problem. Leave with a clearer decision.
We’re preparing the first three to five design-partner conversations around a concrete store problem. The next step is a fit discussion; a monitor-only installation follows only when the authorised route and readiness checks are complete.
Discuss a pilotWho this is for
A Shopify merchant or authorised agency with recurring unwanted activity, existing protection in place, and someone able to review real examples. You may be struggling to explain repeated cart activity, distinguish suspicious sessions from ordinary shoppers, or understand why your current reports and business outcomes disagree.
The useful starting point is one answerable question about an observable workflow. If you need immediate attack containment, universal checkout blocking or card-testing prevention, this monitoring evaluation cannot supply that intervention. Keep using your existing protection and support arrangements.
One workflow. An agreed review date.
Agree the start date, review date and minimum useful activity before installation. A quiet fortnight does not demonstrate protection. If too little relevant activity occurs, record an inconclusive result and explicitly agree whether to extend the pilot.
- Define the question. Agree one workflow, the source of the complaint, the normal activity to compare, and the decision the final review should help you make.
- Check coverage and install eligibility. Confirm the authorised Shopify route, permissions, consent, activation, budgets and a way to stop collection. Live-store validation and public app approval remain pending.
- Observe alongside existing protections. Keep the store’s current controls in place. Blokk starts in monitor mode; collection must not depend on removing another app or weakening a checkout control.
- Review evidence together. Inspect a bounded sample, confirm or correct outcomes where possible, and record unknowns. Include ordinary shopper controls and gaps from absent or delayed observations.
- Make an explicit decision. Review the report at the agreed end date. Stop, agree a separately scoped extension, or continue with the recurring package when the supported protection workflow and commercial terms are ready.
What the evaluation should deliver
A reviewable session sample.
Scoped actions, occurrence and receipt times, reasons, rule versions and missing evidence. A browser session is not an authenticated person.
A record of what was established.
Confirmed, unresolved and corrected findings with their basis. Show denominators and sampling; distinguish policy matches from executed actions.
A bounded end-of-evaluation report.
What the evidence helped explain, what it could not establish, and the next supported action. No invented savings, conversion lift or all-store detection rate.
What a reviewable session could look like
One pixel session reports four distinct checkout-start events. These are untrusted browser observations, not four confirmed orders or payment attempts. Times below are the example’s reported occurrence times, relative to its first event.
| Reported time | Event |
|---|---|
| 00:00 | checkout_started |
| 00:20 | checkout_started |
| 00:42 | checkout_started |
| 01:10 | checkout_started |
Review cue: Repeated activity to review. This describes a question for the merchant, not a proven automation classification.
- Actor identity: unknown. A pixel session does not identify a person.
- Purchaser authorisation and intent: unknown.
- Executed action: none. Monitoring did not block a checkout.
- Business outcome: unresolved.
Check for duplicates, delayed delivery, normal navigation and relevant merchant records before drawing a conclusion. After independent review, the merchant may report legitimate or confirmed unwanted activity, with a basis, or leave it unresolved. A later correction remains part of the record.
Agree the finish before the start.
Before installation, define the minimum usable sample and ordinary shopper controls for your workflow, the people reviewing outcomes, and the evidence needed for the final decision. No universal sample threshold or detection percentage is assumed. At the review, ask whether the findings made the agreed question more answerable and whether the operational burden was acceptable.
Stop collection if the agreed access, privacy or performance conditions are not met. If useful evidence does not arrive, record the coverage gap and close or explicitly rescope the evaluation. An inconclusive result does not silently become an indefinite free beta. Confirm retention and deletion handling when the evaluation ends.
One product, with a bounded evaluation.
Design partners use the shared Blokk product and the same evidence model. The evaluation has a fixed workflow and review date. It does not include bespoke integrations or an open-ended investigation. The recurring package will continue the same supported workflow, merchant controls and outcome reporting, once protection has been demonstrated.
Commercial terms
One bounded pilot, followed by an optional recurring package when its protection workflow is demonstrated. Coverage, observation allowance, support, review date and any fees are agreed in writing before onboarding. No public paid plan is available; discussing a pilot creates no charge.
An initial conversation establishes fit. It does not enrol you in a free trial or a subscription. Any paid evaluation needs a concrete deliverable, acceptance criteria, start and end dates, and a permitted commercial arrangement. No fee or automatic renewal is implied by this page.
Inspect current Shopify coverage and read the pricing status.
Discuss a pilot