A consent architecture that works across projects

Web applications frequently embed external services such as analytics, maps, videos or appointment booking. That creates additional data flows and raises the question of the conditions under which those services may load at all.

Many consent solutions are integrated into a website afterwards, as a system of their own. That creates additional dependencies: configuration and interface sit outside the actual application, external scripts become part of the technical loading path, and control over individual integrations is spread across several systems.

For our projects we therefore wanted to integrate consent directly into the application architecture.

The result is a standalone consent engine that is used today as a shared technical module.

The consent system deliberately separates the central functional logic from project-specific data and the visible interface.

As a result, the same technical foundation can be used in applications that are built very differently, without having to reimplement consent state, versioning or script gating for every project.

A central requirement was not merely to disable consent-dependent services before consent is given. They should not load in the first place.

Several mechanisms work together to achieve this.

So that declared storage values and the actual implementation are not maintained independently of one another, the engine uses a central registry. Technical properties are defined for every storage value managed through the consent infrastructure.

Language-dependent information such as purpose and description is maintained separately from this.

If application code attempts to write an unregistered value through the consent infrastructure, the operation is rejected. The registry is therefore not just documentation but part of the technical control.

Every consent configuration carries a version.

On a subsequent visit the engine compares the stored version with the version currently in use. If the configuration has changed accordingly, the existing selection can be discarded and a new decision requested.

A newly added service can therefore be handled through a new consent version, without developing migration logic for every individual website.

Consent can be adjusted at any time through the consent settings. If a previously accepted category is deselected, more changes than just the stored consent state.

The rebuild matters because third-party scripts that have already run cannot be reliably undone by removing their script element alone.

After withdrawal, the state should therefore match that of a visitor who never released the category in question.

A defined interface sits between the consent engine and the configuration. The engine needs certain information but is not tied to where that information is stored.

This makes different models possible.

Cookie names, identifiers, category assignment and storage durations are language-neutral. Everything visitors read, by contrast, can be maintained per language.

A storage value is therefore defined technically once and then described for every language required.

In the reference project Woop Art, German and English are fully maintained. The Woop Technology website uses the same engine with additional languages.

The engine provides a reusable default interface but does not prescribe its use.

The consent logic remains unchanged throughout.

The presentation can therefore be adapted to the design system of the respective project without reimplementing central functions such as versioning, registry or withdrawal.

In addition to the consent state in the browser, every explicitly saved decision can be logged server-side.

IPv4 addresses are truncated after the second block, IPv6 addresses after the third segment.

The endpoint provided for this accepts requests from its own origin only and sits on a fixed path, so that it can also be restricted deliberately at infrastructure level.

The visitor's decision takes effect in the application's consent state first. If the additional server-side storage fails, the website remains usable.

The error is logged server-side instead of exposing technical details in the browser. The consent system's ability to function therefore does not depend on the additional logging being available at every moment.

The consent configuration and the central engine are part of the application itself. No external CMP provider is therefore required for the consent system.

Consent-dependent services remain separate from this and load only once the required consent is in place.

The consent engine exists as a package of its own and is provided through the private package registry of Woop Technology. Versions and changes can therefore be managed as traceably as any other technical dependency.

A new project essentially adds four project-specific areas.

A consent architecture of your own is not necessary for every project. For a simple website with few external services, an established consent platform can be the faster and more economical solution.

In those cases a shared engine reduces project-specific implementations and makes it possible to develop central functions further in one place.

The central consent state is available to application code as well.

This also makes two-click solutions possible. Instead of a third party that has not yet been released, a local component can be shown first, informing about the external service and loading it only after a corresponding decision.

Consent is therefore not limited to banner and settings dialog but can be integrated directly into the flow of an application.

An external consent platform brings an additional provider, its own scripts, its own configuration and usually one more technical dependency. Our own engine, by contrast, is operated together with the existing applications and within the intended infrastructure.

This does not mean that external consent platforms are generally unsuitable. The decision depends on the scope and requirements of the respective project.

No further CMP provider is required for managing consent itself. The corresponding consent data can therefore be processed where the application is operated.

Which other external services a specific project uses, and which data is transferred in the process, is defined and documented project by project, independently of this.

The consent engine is used today as a reusable part of different web applications. Central functions are maintained once, while data, integrations, languages and interface remain project-specific.