Customer profile and consent before marketing automation

1. Separate the person, the visit, the consent and the execution.

In day-to-day work it's easy to squeeze everything into one sentence: "We have a customer, so we can send a message." Technically, that sentence hides several different facts. A customer record may contain contact details and still have no link to the current visit. A linked visit may be visible without the active consent needed for a particular action.

Before you launch a scenario, go through the four questions in the table. That way you'll explain more quickly why a contact received a tag or why an action was skipped. You don't have to guess based on how the profile looks. In Flowprofile you can check recognition and the person's available context, and in the automation history — how the action went.

2. Check where the profile data comes from.

Flowprofile can receive data through different routes. In WooCommerce, the integrated plugin handles login, registration and selected forms, among other things. In IdoSell, PrestaShop and Shopify, the available customer stream also makes it possible to recognize a person who hasn't placed an order. The exact scope depends on the integration and the data that's shared.

Not every anonymous visit becomes a profile with an e-mail address. Flowpeek may pull customer data from the store but have no confirmed link to that person's earlier anonymous visits. In Shoper, the current order-based route doesn't provide the same range of consent sources or profiles without a purchase. During setup, agree on the specific recognition path instead of assuming every platform works the same way.

3. Don't fill in missing history.

If the store connection passes on customer data without the information needed to link it to a visit, the profile won't reconstruct the earlier history. Order history and behavior history have different scopes. A missing link is information about the data, not proof that the customer never visited the store before.

Pick one controlled example and check the path from visit to recognition. See whether the profile update matches the action taken in the store. Then compare what you see in the user journey. Don't link people based only on similar behavior, a name or visit time. This caution helps you avoid wrong personalization and sending an action to the wrong contact.

4. Check the purpose and currency of consent.

When processing is based on consent, the EDPB guidelines describe the requirements that it be freely given, specific, informed and unambiguous, as well as the ability to withdraw it. These are principles you need to apply to the actual process in your store. A purchase or creating an account isn't automatically proof of consent to any marketing communication.

On the operational side, check the source of the consent status, its purpose, the date it was updated and how a change is passed to the integration. Establish what happens after someone unsubscribes and whether a later import restores an outdated status. Consult the person responsible for data protection about the choice of legal bases, form wording and the requirements for a particular channel. This guide describes process checks and product capabilities; it doesn't replace a legal analysis of your store.

5. Separate the setup method from consent handling.

A custom domain helps organize how measurement works technically. Sending an event from the server can supplement the data available from the browser. Neither of these choices on its own determines your right to further use information about a person. Don't equate a server address with the scope of consent.

For example, Google's official documentation for server-side tagging describes passing on consent status and adjusting how tags behave. This shows that a server-side architecture also requires deliberate signal configuration. In your own setup, trace the entire flow: the form or customer settings, the integration source, the profile and the target action. The promise that "server-side collects everything" ignores these differences and isn't a proper acceptance criterion.

6. Test a consent change during the scenario.

Consider a scenario: a customer adds a product to the cart, the automation waits three hours and then is supposed to add a tag in the marketing tool. In that time, the customer may buy or withdraw consent. The status at the moment of entering the scenario shouldn't be the only basis for a later action.

Flowpeek checks the contact link and consent again before each action. In a controlled test, check the variant with no changes and the variant where consent is withdrawn during the delay. Read the execution history: a skipped action can be the correct result, not a failure. Check the target platform's response separately, because adding a tag or changing a field isn't the same as a message being sent.

The editor shown has a 30-minute delay. Use that window for a controlled consent-change test: start the scenario for your own test contact, change the status at the integration source and check that it's updated before the action. The diagram alone doesn't show a particular person's current consent status — to evaluate it, you need the profile, the execution history and the status in the target tool.

• Contact recognized, consent current: check the expected action.
• No contact link at entry: check that the visitor doesn't enter the scenario.
• Consent withdrawn during the wait: check the status before the action.
• Purchase before the delay ends: check the purchase condition branch.

7. Write down the operating rules and the test result.

For your first scenario, write down its goal, contact source, target platform name, trigger and action condition. Add controlled examples and expected results. A description like this helps whoever takes over the store understand why a process works, without reconstructing every decision from memory.

Regularly check integration errors and skipped cases. Don't try to increase the number of executed actions by removing consent checks. If many events don't find a contact, start with recognition and the integration scope. If the contact exists but the status change doesn't reach the platform, trace the sync. Separating these problems shortens diagnosis and helps you build communication based on the customer's actual context.