Personalization Mode

Personalization Mode lets you control how much user data Moloco uses when serving ads and measuring performance for a given request. You set the mode per request using the personalization_mode field, so you can align ad serving with each shopper's consent state and with your platform's privacy requirements.

Overview

For each decision or user event request, personalization_mode determines two things:

  1. Whether Moloco uses the shopper's event history to personalize the ads that are served. Personalized Ads are the result of our ML Model and this model is trained by both Catalog Feed and User Events. See reference here.
  2. Whether Moloco uses a user identifier to attribute downstream events (such as purchases) back to the ad.

There are three modes:

  • STANDARD - full personalization and full attribution.
  • METRIC_ONLY - no personalization from event history, but attribution is still measured.
  • ID_LESS - no personalization and no attribution.

personalization_mode is optional. If you omit it, the request behaves as STANDARD.

📘

Note on consent and data responsibility:

Personalization Mode gives you a mechanism to reflect each shopper's consent choice in the request. You remain responsible for determining the correct mode for each shopper based on whether the user falls under a jurisdiction that requires consent, the consent you have collected and your applicable privacy obligations.


Modes at a glance

ModePersonalization from event historyAttribution measuredUser identifier requiredUser identifier allowed
STANDARD (default)YesYesNoYes
METRIC_ONLYNoYesYesYes
ID_LESSNoNoNoNo

STANDARD

STANDARD is the default mode and provides the full Moloco experience:

  • Ads are personalized using the shopper's user event history together with contextual information from the request.
  • A user identifier, when provided, is used to attribute downstream events back to the ad so that campaign performance metrics (such as attributed purchases and revenue) are available.

If personalization_mode is omitted from a request, Moloco processes it as STANDARD. This keeps existing integrations working without change.

METRIC_ONLY

In METRIC_ONLY mode:

  • Ads are served using contextual information only. The shopper's user event history is not used to personalize the ads.
  • A user identifier is still used to measure attribution, so campaign performance metrics remain available.

Because attribution requires a user identifier, a request in METRIC_ONLY mode must include at least one user identifier. If no user identifier is provided, the request is rejected.

Use METRIC_ONLY when a shopper has not consented to personalized advertising but you still need accurate performance measurement.

ID_LESS

In ID_LESS mode:

  • Ads are served using contextual information only, with no personalization.
  • No user identifier may be sent. If a request in ID_LESS mode includes any user identifier, the API returns a 400 error.
  • Because no identifier is used, attribution is not possible and no user-level performance metrics are produced for the request.

Use ID_LESS when a shopper has not consented to the use of their identifier for advertising purposes.

Effect on ad serving and model training

Personalized ads are produced by a machine learning model that is trained on your catalog feed and on user events. For more detail on how these inputs are used, see Ad serving configurations.

The table below summarizes what each mode does with user data, including whether the user events sent on a request are used to train the personalization model.

BehaviorSTANDARDMETRIC_ONLYID_LESS
User identifier acceptedRequiredRequiredNot allowed
Ad response personalized from user event historyYesNoNo
Contextual signals used for ad servingYesYesYes
Attribution metrics (such as attributed purchases and revenue)YesYesNo
Impression and click counts collectedYesYesYes
User events used to train the personalization modelYesNoNo

What counts as a user identifier

A user identifier is any field that can identify the shopper. The exact fields depend on the API:

  • Decision APIs — identifiers provided on the user object, such as user.user_id and any device or advertising identifiers.
  • User event API (PostUserEvent) — the top-level user_id field and any associated identifiers.

For METRIC_ONLY, at least one such identifier must be present. For ID_LESS, none of these identifiers may be present.

Supported APIs

personalization_mode is supported on the following APIs:

  • DecideAdProducts
  • DecideAdBrands
  • DecideAdDisplay
  • DecideAdReservedDisplay
  • PostUserEvent (user event ingestion)

Set the field on each request where you want to control personalization and attribution behavior.

How the mode is applied

Per-request behavior

personalization_mode applies only to the request it is set on. The mode used on one request does not carry over to, or change the behavior of, any later request. You can send different modes for the same shopper across different requests.

Data usage across modes

Data collected under METRIC_ONLY or ID_LESS is never used to enhance ad personalization, even for the same shopper on a later request:

  • If a shopper is served under METRIC_ONLY or ID_LESS, that activity does not feed personalization.
  • If the same shopper later sends a STANDARD request, only their STANDARD-eligible history is used for personalization; the earlier non-personalized activity is not retroactively added. 

This ensures that a shopper's non-consented activity does not influence personalized advertising.

Mode-switching scenarios

ScenarioResult
Shopper sends STANDARD, then later METRIC_ONLYThe METRIC_ONLY request is served contextually (no personalization); attribution is still measured. The earlier STANDARD history is not used to personalize the METRIC_ONLY request.
Shopper sends METRIC_ONLY, then later STANDARDThe STANDARD request is personalized using STANDARD-eligible history only. Activity captured under METRIC_ONLY is not used for personalization.
Shopper sends ID_LESS, then later STANDARDThe STANDARD request is personalized normally from STANDARD-eligible history. The ID_LESS request contributed no identifier and no personalization data.

Compatibility

  • Backward compatible. Existing integrations that do not send personalization_mode continue to work and are treated as STANDARD.
  • Case-sensitive values. The mode values (STANDARD, METRIC_ONLY, ID_LESS) are case-sensitive.
  • Unknown values. A value that is not recognized is treated as STANDARD.

FAQ

What happens if I do not set personalization_mode?

The request is processed as STANDARD, with full personalization and attribution.

Can I use METRIC_ONLY without a user identifier?

No. METRIC_ONLY requires at least one user identifier so that attribution can be measured. A request without an identifier is rejected.

What happens if I send a user identifier with ID_LESS?

The API returns a 400 error. ID_LESS requests must not contain any user identifier.

Does a shopper's non-personalized activity ever affect future personalized ads?

No. Data collected under METRIC_ONLY or ID_LESS is never used to enhance personalization, including for the same shopper on later STANDARD requests.

Does the mode I send persist for the shopper?

No. personalization_mode applies only to the request it is set on and does not change the behavior of later requests.

If a user consents and then removes its consent later on, are ads still personalised based on old history?

No, if a user had consented in the past (STANDARD personalisation mode) and later removes its consent (METRIC_ONLY or ID_LESS Personalisation mode) Ads will stop being personalised and will not be personalised based on past User Events (even if they were on STANDARD Personalisation mode) for this user and user events will no longer personalise the existing model. 

 

If you wish to delete user data you can also refer to our User Data Deletion Request API


Did this page help you?