> Part of the walkerOS documentation. Project overview and full index: <https://www.walkeros.io/llms.txt>

# Consent management

Managing user consent is critical for legal compliance and user privacy. WalkerOS follows a **privacy-by-design** approach and offers multiple ways to handle consent and manage data processing to ensure the user's privacy is respected.

warning

We don't give any legal advice. Make sure to consult a legal expert to ensure that your implementation is compliant with the laws and regulations that apply to your business.

Typically, a Consent Management Platform (CMP) handles the consent. This is an asynchronous process. The CMP has to be loaded, a user has to make a choice, and/or the state has to be updated. walkerOS provides [CMP source packages](https://www.walkeros.io/docs/sources/web/cmps.md) that automate this. They listen for CMP events and call the consent command for you.

To set/update the consent state, the CMP should actively push the `consent command` with a group or an individual tool's permission state (`true/false`). If only one condition applies, consent is granted. Updating only one value won't override existing states.

```
elb('walker consent', { functional: true, marketing: false });
```

Consent keys can be defined arbitrarily (typically known as *functional*, *analytics*, and *marketing*). However, you can also use individual names for each vendor.

The walker handles the **race conditions**: Previously pushed events get processed in the correct order after granting the consent state with the destinations as well as new ones.

### Destinations[​](#destinations "Direct link to Destinations")

With each event, the consent states get checked. Every event will be added to an ordered queue if consent isn't granted yet and the destination's queue isn't disabled. The queue resets with each `walker run` command. And will be (re-)processed with each `walker consent` update. The key must match the key used in each `destination.config.consent`.

note

The queued events properties `consent`, `globals`, and `user` will be **updated** to the current state before being processed.

note

A destination only requires one granted consent state to process events.

To revoke consent and stop sharing events with a destination, all matching rules have to be set to `false`:

```
elb('walker consent', { marketing: false });
```

## on consent[​](#on-consent "Direct link to on consent")

To start walker.js only after a consent choice, use the `on consent` command:

```
// Wait for functional consent to run
elb('walker on', {
type: 'consent',
rules: {
functional: () => {
elb('walker run');
},
},
});

// Later, a CMP has to update the consent state
elb('walker consent', { functional: true });
```

Another example of how to use the `on consent` command might be to update [Googles consent mode v2](https://developers.google.com/tag-platform/security/guides/consent?consentmode=basic):

```
elb('walker on', {
type: 'consent',
rules: (consent, context) => {
// Check if marketing consent is granted
if (consent.marketing) {
gtag('consent', 'update', {
ad_user_data: 'granted',
ad_personalization: 'granted',
ad_storage: 'granted',
analytics_storage: 'granted',
});
}
},
});
```

The consent mode will be updated via `gtag` as soon as marketing consent is granted.