Cheetah Digital Standard Data Load

Cheetah Digital by Zeta is a customer engagement platform that helps marketers deliver personalized experiences, create effective cross-channel messaging, and increase customer loyalty.

Send a customer record to Cheetah Digital as soon as Amperity sees the customer interaction, using the Standard Data Load API. Amperity sends one request for each real-time point. Each request names an API Post and carries one record built from the customer’s attributes.

To send records with a campaign ID and a table instead of an API Post, use the Cheetah Digital Advanced Event Trigger connector. To send files on a schedule rather than in real time, use the Cheetah Digital destination.

This connector sends from a real-time journey. See Real-time destinations.

Requirements

  1. The API Post must exist in Cheetah Digital before a journey sends to it. See API Posts in the Cheetah Digital documentation.

Credentials

The Cheetah Digital Advanced Event Trigger and Cheetah Digital Standard Data Load connectors use the same credential type, “cheetah-digital”. One credential can serve both.

Name and description

The name and description for a credential.

Username

Required. The username for Cheetah Digital API authentication.

Password

Required. The password for Cheetah Digital API authentication.

To find these values, see API Keys in the Cheetah Digital documentation.

Amperity exchanges the username and password for an OAuth 2.0 access token, and sends that token with each request. Amperity requests the token from “https://api.eccmp.com” for every region.

Note

When you save the destination, Amperity tests the connection by requesting an access token. The test checks the username and password only. It does not check the region, or the values that an Activate node sends.

Settings

Name and description

The name and description for a destination.

Business user access

By default a destination is available to all users who have permission to view personally identifiable information (PII).

Enable the Admin only checkbox to restrict access to only users assigned to the Datagrid Operator and Datagrid Administrator policies.

Enable the PII setting checkbox to allow limited access to PII for this destination.

Use the Restrict PII access policy option to prevent users from viewing data marked as PII anywhere in Amperity and from sending data to downstream workflows.

Region

The region that hosts your Cheetah Digital account. May be “North America”, “Europe”, or “Japan”. Defaults to “North America”. Amperity sends each request to the API host for this region:

Region

Advanced Event Trigger

Standard Data Load

North America

aet.eccmp.com

api.eccmp.com

Europe

api.ccmp.eu

api.ccmp.eu

Japan

aet.marketingsuite.jp

api.marketingsuite.jp

Activate node settings

The rest of the configuration for this connector belongs to the journey that sends to it. Add this destination to an Activate node, then configure the following fields on that node. Two nodes may send to the same destination with different API Posts and custom attributes. Mapped attributes are set once for the destination in the journey, so every node that sends to it uses the same mapped attributes.

form_id

Required. A whole number. The Form ID of the API Post. To find it, see API Posts in the Cheetah Digital documentation. Amperity sends it as “apiPostId”. The node shows an error until this field is set to a whole number.

Attributes

The attributes mapped on the node’s Attributes tab, including custom attributes, are sent as name and value pairs, under the destination attribute names they are mapped to. A custom attribute with the same name as a mapped attribute replaces it.

Amperity converts every value to text before it sends it:

  • Numbers and true or false values are sent as their text form, such as “42” or “true”.

  • A date value (a date with no time) is sent in “YYYY-MM-DD” format, and a datetime value is sent as ISO 8601 text.

  • A profile attribute that the customer’s profile has with an empty (null) value is sent as an empty string.

  • A list or map is converted to text as a whole, so map attributes that hold a single value.

Destination attribute names may contain only letters, numbers, dashes (-), and underscores (_). Each name must be unique on the node and may not be blank, and the node needs at least one attribute. When you edit the node’s attributes, Amperity flags any name that breaks these rules.

A profile attribute that the customer’s profile does not have, and an enriched or custom attribute with no value, is left out of the record.

Request body

Each request carries the Form ID, the record’s name and value pairs, and two validation flags that Amperity always sets to true: “enable_validation” and “validate_on_error”.

For example, with form_id set to 1234 and attributes mapped to “email” and “points”:

{
  "apiPostId": 1234,
  "enable_validation": true,
  "validate_on_error": true,
  "data": [
    {"name": "email", "value": "customer@example.com"},
    {"name": "points", "value": "42"}
  ]
}

Failed sends

Amperity makes up to three attempts at each send. Within an attempt, Amperity retries the request up to five times, with increasing waits, after a connection error, a request timeout (408), a rate limit error (429), or a server error (5xx).

How Amperity handles each failure:

  • 401 or 403. The send fails without another attempt. The error says that Cheetah Digital rejected the credential. Check the username and password in the destination’s credential.

  • 400. The send fails without another attempt. When the response says that a unique field is not set, the error names that field, if the response names it. Map an attribute to that field that has a value for every customer. For any other 400, check the values that the Activate node sends.

  • 404. Amperity makes another attempt, up to three in all. Check the values that the Activate node sends.

  • Any other failure, including a 429 or server error that persists through the retries, gets another attempt, up to three in all.

Amperity does not send a deduplication key with a request, so a request that Amperity sends again is not marked as a repeat of an earlier one.