Send Custom Events

Overview

CHEQ Custom Events let you send named actions (signups, purchases, form submissions, button clicks, and so on) directly to CHEQ from the front end. Each event is associated with a CHEQ verdict, so you can see which actions are taken by verified human users and which come from bots, scrapers, proxies, and other invalid traffic.

Events serve two purposes:

1. Context. Any event gives you visibility into how different traffic types behave on your site.
2. Policy calibration. Events you mark as Conversions surface in the Suspicious Signals Review inside Policy Management, so you can fine-tune Allow vs. Block decisions based on real business impact rather than aggregate traffic composition alone.

CHEQ's data model is event-based. Every server call sent to CHEQ carries an associated event, including the call fired when the library first loads.

How it works

When the CHEQ library loads, it exposes a global JavaScript object, window._cq. You push events onto _cq.events, and CHEQ ingests them with a timestamp and the session's current detection verdict.

A system event named cheq_loaded is set automatically every time the CHEQ library loads. This is how CHEQ currently increments a "Pageview" and it exists for all properties without any setup on your part.

In the CHEQ interface, an Events tab appears under Settings in both Analytics and Acquisition. There you can see incoming events and toggle individual events on as Conversions.

Prerequisites

• The CHEQ library must be installed and loading on the page.
• Access to the Events tab (Event Tracking and Conversions is generally available; some related controls may still be access-gated for your account).
• Recommended: a Tag Management System (CHEQ Manage, Google Tag Manager, Adobe Launch, Tealium, or similar) where triggers for key actions are already defined. Custom events piggyback cleanly onto those existing triggers.

Basic implementation

Fire the following code when a meaningful action occurs:

window._cq = window._cq || (_cq = { events: [] });
_cq.events.push({ event: "EVENT_NAME" });

Replace EVENT_NAME with the name of your event. The event name can be any string (for example purchase, submit_form, newsletter_signup).

The first line is important: it guarantees the _cq object exists before you push to it, so the event is not lost if it fires before the library has fully initialized.

Example

window._cq = window._cq || (_cq = { events: [] });
_cq.events.push({ event: "purchase" });

This sends a purchase event to CHEQ, populating the Events screen and providing context to your policy rules.

Event payload reference

Example with a user identifier:

_cq.events.push({ event: "submit_form", uvid: "23958723985298375" });

Related _cq methods

These are part of the same JavaScript SDK and may appear in your implementation:

// Associate a first-party ID with the CHEQ user (UVID)
_cq.set({ user_id: someUserId });

// Target one or more Properties (e.g., a brand Property plus a roll-up Property)
_cq.set({ setProperty: ["OASIJI22", "ABAVK124"] });

Deploying via Google Tag Manager

1. Create a new Custom HTML tag.
2. Paste the event code inside <script> tags:

<script>
  window._cq = window._cq || (_cq = { events: [] });
  _cq.events.push({ event: "purchase" });
</script>

3. Attach the tag to a pre-existing trigger for the action (for example, your existing Purchase trigger).

Because the snippet piggybacks on triggers you have already defined, no new trigger logic is usually required.

Deploying via Adobe Launch

1. Use an existing rule, or create a new rule, that fires when the action occurs.
2. Add a Custom Code (JavaScript) action to that rule.
3. Paste the event code into the action:

window._cq = window._cq || (_cq = { events: [] });
_cq.events.push({ event: "submit_form" });

4. Save the rule, test in a Development library, then publish.

The same pattern applies to any other Tag Management System: trigger the snippet on the action you want to measure.

Marking events as Conversions

1. Open the Events tab under Settings (in Analytics or Acquisition).
2. Locate the event you want to elevate.
3. Toggle the Conversion switch on the right-hand side.

You can mark any number of events as Conversions, including none.

Marking an event as a Conversion enables conversion and conversion-rate columns in the Suspicious Signals Review within Policy Management. These columns let you see whether a given traffic type (bots, scrapers, proxies, and so on) is actually completing the actions that matter, which can influence whether you Allow or Block that traffic.

Important: These columns only appear for events that are marked as Conversions. In Analytics, marking an event as a Conversion does not currently change Analytics reports.

Limits and considerations

• 50 events per page. Events are capped at 50 per page. There are no per-session or per-user limits.
• Timing. The CHEQ library loads asynchronously, so a verdict may not be available the instant the page loads. The window._cq = window._cq || ... guard ensures events are not dropped, and CHEQ associates each event with the session's last known verdict.
• Naming. Use clear, consistent event names. They become the labels you analyze and the basis for policy decisions, so a stable naming convention pays off.

Where event data appears

• Events tab (Settings, in Analytics and Acquisition): event list and Conversion toggles.
• Policy Management / Suspicious Signals Review: conversion and conversion-rate columns for events marked as Conversions.
• CHEQ Inspector: drill into individual sessions and analyze interaction pathing from tracked events. Sessions are grouped by a session cookie (_cq_session).

System and reserved events