Common events

page_view

The page_view call lets you record whenever a user sees a page of your website, along with any optional properties about the page.

Parameters (required and recommended)

Automatically added parameters by cact API for web sources

Example

cact('trigger','page_view', {
  page_type: 'product_list',
  page_name: 'Best sellers',
  user: {
    id: '12356',
    email:'toto@domain.fr',
    consent_categories: [1,3]
  }
});

login

Send this event to signify that a user has logged in.

Parameters

Example

cact('trigger', 'login', {
  method: 'LinkedIn',
  user: {
    id: '12356',
    email:'toto@domain.fr',
    consent_categories: [1,3]
  }
});

Use this event to contextualize search operations. This event can help you identify the most popular content in your app.

Parameters

Example

cact('trigger','search', {
  search_term: 't-shirts',
  user: {
    id: '12356',
    email:'toto@domain.fr',
    consent_categories: [1,3]
  }
});

select_content

This event signifies that a user has selected some content of a certain type. This event can help you identify popular content and categories of content in your app or click on internal promotion.

Parameters

Example

cact('trigger','select_content', {
  content_type: 'product',
  item_id: 'I_12345',
  user: {
    id: '12356',
    email:'toto@domain.fr',
    consent_categories: [1,3]
  }
});

sign_up

This event indicates that a user has signed up for an account.

Parameters (required and recommended)

Example

cact('trigger','sign_up', {
  method: 'email',
  user: {
    id: '12356',
    email:'toto@domain.fr',
    consent_categories: [1,3]
  }
});

- COMMON SCHEMAS -

User

When you send an event, it needs to carry enough information to identify which user made it. We can link events together using cookies. But destination partners require accurate identifiers to take actions.

id and email are usually the most useful parameters. Though some destination partners also use firstname, lastname, birthdate, city, ...

You won't always have all of those parameters. But it is recommended to send them as soon as you can during user's browsing.

Parameters (required and recommended)

About Hashing

In some cases, you won't be able to send a parameter plain value. It is either unavailable or restricted.

Thus it might be possible to send the hashed values. We currently accept 2 algorithm : md5 and sha256.

Every user.<property> can be sent under hashed format with algorithm suffix: _md5 or _sha256 (underscore followed by lowercase algorithm name)

Example :

{
  user: {
    email_md5: '8eb1b522f60d11fa897de1dc6351b7e8',                                      // md5('john.doe@example.com')
    email_sha256: '836f82db99121b3481011f16b49dfa5fbc714a0d1b1b9f784a1ebbbf5b39577f',   // sha256('john.doe@example.com')
    phone_md5: '60dd761f55cb17f0532c9fb1679e8ddd',                                      // md5('+33612345678')
    phone_sha256: '42d573cfc315801d4cd8eddd5416b416a0bf298b9b9e12d6b07442c91db42bd8',   // sha256('+33612345678')
  }
}

No need to send both plain and hashed values :

  • if you send plain value, the hashed values aren't necessary We can generate hashed values on server side using plain value

  • if you don't send plain value, then you should fill as much hashed values as possible Partners require different hash algorithms and without plain value, we can't generate any hash. That's why we need the exact hashed value

Last updated