Targeting Storage

To persist data between requests, the targeting engine uses a targeting storage service responsible for persisting the given data. The storage always receives the VisitorInfo instance it should store or retrieve data for, and a scope that defines how the data is handled.

There are two fixed scopes, used depending on what's needed:

Scope	Description
session	Valid for the current session, expires afterwards. Depending on the implementation, a session is defined either by a timeout of inactivity or natively by the storage system. The DB and Redis storages expire data after a set amount of time, while the Session and Cookie storages rely on the session and cookie lifetime.
visitor	Valid for the whole lifetime of the visitor. When a visitor returns with its unique ID, its data is still usable while session data would have expired.

Configuring the Targeting Storage

Define the targeting storage as a service, and configure its service ID with the following config entry:

pimcore_personalization:
    targeting:           
        storage_id: Pimcore\Bundle\PersonalizationBundle\Targeting\Storage\CookieStorage

Implement a Custom Targeting Storage

A targeting storage is a class implementing TargetingStorageInterface, registered as a service. How you handle the data varies heavily by underlying storage, but you can take the shipped storages as a starting point.

Core Storage Implementations

Pimcore implements several storage engines, each with its own pros and cons. Start with the default implementation, JWT signed cookie, and switch to whichever engine best fits your requirements.

Future releases may add storage implementations that combine features of multiple engines, for example a storage that picks between backends depending on whether the visitor already has a visitor ID.

Cookie (default)

Stores data in a cookie in the user's browser, either as plaintext or JWT-signed to prevent tampering with the cookie data. The cookie storage delegates the actual cookie read/write operations to a CookieSaveHandler. Below is an overview of the shipped save handlers:

Handler	Description	Notes
JWT (default)	Stores cookie data as JWT signed JSON using the kernel.secret parameter to sign and verify the data. This is done to make sure the data can't be altered on the client side to inject malicious data into the targeting engine.
JSON	Stores cookie data as JSON string.	Use only for testing!

To change the save handler, override the CookieStorage service definition and set your own handler.

danger

Plain text cookie data is inherently insecure and can open vulnerabilities by letting an attacker inject malicious data into the client cookie. Use only for testing.

Default session scope timeout: 30 minutes. The JWT handler also enforces this by setting the signed data's expiration to the same timeout as the cookie, so even if someone changes the cookie lifetime on the client side, the data still expires when read on the backend.

Pros

• Easy to use, no additional config needed, and it can store data without needing a visitor ID.
• Fast and easy to debug.

Cons

• Cookie size is limited and bloats requests; only use it when the amount of generated targeting data stays small.
• Inherently insecure when used with an unsigned cookie.

Db

Stores data in the database.

Default session scope timeout: 30 minutes

Pros

• Easy to use as no additional config is needed

Cons

• Can only store data when a visitor ID is present as the ID is part of the primary key
• DB can fill up quickly - not to be used on large sites

Redis

Stores data in a Redis database. To use this storage, define a service using the storage implementation as its class and add connection details to the service definition. An example is shipped (commented out) in config/targeting.yaml.

Default session scope timeout: 30 minutes

Pros

• Can efficiently handle large amounts of data
• Natively supports data expiration

Cons

• Can only store data when a visitor ID is present as the ID is part of the key
• Needs a dedicated Redis DB independent of the cache one (needs to be configured on the service definition)

Session

Stores data in the session.

Default session scope timeout: PHP session timeout

To use the session storage, an additional config entry is needed as the session listeners are disabled by default for performance reasons:

pimcore_personalization:
    targeting:
        # enable session support
        session:
            enabled: true
            
        # use the session storage
        storage_id: Pimcore\Bundle\PersonalizationBundle\Targeting\Storage\SessionStorage

Pros

• Easy to use as no additional config is needed
• Can store data without a visitor ID

Cons

• Can't persistently store data for a visitor
• Session size is limited
• Slow depending on session storage
• Might not work properly in conjunction with full page caches. Pimcore's full page cache is disabled when the session contains targeting data, but if using something else it might be difficult to handle. Use with care when using full page caches!