Start with the question you need answered
A traffic monitor helps answer what your store observed. A checkout control answers whether a particular purchase can continue under a rule. Connecting a monitor does not automatically activate that rule, and seeing an automation indicator does not prove that a purchase was stopped. These distinctions matter when checking a new installation or deciding whether to enable protection.
In Blokk Bot, monitoring comes first. Dashboard shows supported recorded activity and findings, Settings holds the connections and preferences, and Plan handles the subscription. You should be able to understand the current state without reviewing every ordinary session. A quiet dashboard, however, still needs to be interpreted alongside connection status and the last activity received.
Monitoring depends on the activity that reaches it
Blokk uses its theme extension and Shopify customer events to observe supported storefront activity. The connection must be active, the browser must execute it and the required consent must allow collection. An app installation alone does not establish those conditions. A client that never runs the integration cannot supply its browser evidence.
Shopify’s Web Pixels API provides customer-event subscriptions in a sandboxed environment. This is a source of observations, not an edge firewall around every request to the store. Blokk’s recorded events therefore describe the activity received through its supported connections; they are not a complete count of everything that contacted Shopify.
The current account policy is deliberately specific
Blokk’s implemented account policy concerns repeated automated cart additions from a signed-in account. It requires at least 12 distinct supported cart-add observations within 60 seconds, including three WebDriver assertions and a current assertion. Original dispatch timing and arrival within five seconds are required. Repeated page views, speed alone or a delayed batch do not satisfy this rule.
Those observations remain browser reports. A signed account connection binds the evidence to an account, but does not turn a reported cart action into proof of harmful intent. A permitted account can require different treatment. Guest activity, a different account or concealed automation remains outside this particular account policy.
Preview is a useful step before a response
Free monitoring can include an eligible account-policy preview after its separate setup and acceptance. A preview shows a supported match without creating a checkout restriction. It lets you inspect the reason before considering paid protection. An old match is historical evidence, not an instruction to restrict an account now.
Paid protection also needs an eligible store, supported setup and explicit approval. Blokk’s wider rollout remains gated while live refusal and recovery are being verified. A plan upgrade does not resolve a rollout or platform-setup issue. The current store status is the place to check availability.
Read the result at the right stage
An eligible enabled policy can queue a checkout restriction for the relevant account through the end of the shop’s current day. Publication to Shopify is asynchronous. Shopify validation Functions provide a checkout enforcement surface, but a queued update or a confirmed configuration is still different from a witnessed checkout refusal.
Review the original reason, the current Shopify state and any recovery result separately. Blokk does not convert a policy match into a blocked-purchase count. Before relying on a rollout, test the restricted account, a permitted control account and the restored checkout after release. This establishes a useful workflow rather than an impressive but ambiguous total.