Skip to content
Log in

Audit Event - Liquid Tag Reference

On this page

The audit_event tag records a custom entry in the audit log from a theme. Use it to capture actions that matter to the business but are not standard StoreConnect events, such as a loyalty tier change or a customer deleting a saved address.

Syntax

```liquid

{% audit_event “loyalty_tier_changed” %}

{% audit_event “loyalty_tier_changed”, message: “Upgraded to gold” %}

{%- assign tier_detail = ‘{“from”:”silver”,”to”:”gold”}’ | deserialize -%} {% audit_event “loyalty_tier_changed”, message: “Upgraded to gold”, detail: tier_detail %} ```

Property Value
Tag Name audit_event
Type Simple tag
Output None. The tag renders an empty string
POS support No

Parameters

Parameter Type Required Description
First argument String Yes The name of your event, in quotes. Recorded in Custom Event Name
message String No A short human-readable summary, up to 255 characters
detail Object No Event-specific detail, stored as JSON in Details. Build it with deserialize

Building the detail value

Liquid has no object literal, so build detail with the deserialize filter and pass the resulting object:

```liquid

{%- assign deleted_detail = ‘{“nickname”:”Office”}’ | deserialize -%} {% audit_event “address_book_entry_deleted”, message: “Customer deleted a saved address”, detail: deleted_detail %} ```

:::warning Passing a raw JSON string rather than a deserialized object stores it as an escaped string instead of structured detail, and secret filtering cannot apply to it. Secret filtering matches on key names, so it needs real keys to match against. :::

Recorded values

Every entry the tag makes is recorded on the Audit Log object as:

Field Value
Event Type custom, always
Custom Event Name Your first argument
Category CUSTOM
Severity NOTICE
Channel web
Outcome success
Actor The logged-in customer, when there is one

Event Type is always custom, so a theme cannot record an entry that looks like a standard event such as login or payment_succeeded.

Limits

  • The store must record the Custom category. Because entries are NOTICE, they are recorded only when the store’s Audit Log Level is Standard or Verbose and Custom is one of its Audit Log Categories. Categories are all enabled when Audit Log Categories is blank.
  • Ten entries per request. Further calls in the same request are ignored silently. Do not put this tag inside a loop over products or line items.
  • Secrets are stripped by key name. Any key in a structured detail whose name contains password, passwd, secret, token, api_key, apikey, _key, crypt, salt, certificate, card_number, cardnumber, authorization, ssn, or otp, or is exactly pan, pin, cvv, or cvn, is stored as [FILTERED]. A key that names a secret any other way, such as social_security_number or a bare key, is stored as written. Filtering matches key names, so it cannot redact a secret buried in a plain string. Do not rely on it, and avoid passing sensitive values at all.
  • Length limits. message is capped at 255 characters and detail at 32768. Longer values are truncated rather than rejected, so a detail over the limit is stored as incomplete JSON.
  • A failed write never breaks the page. If the entry cannot be recorded, the tag renders nothing and the page continues. An undefined variable passed as message or detail still shows a Liquid error, because it is evaluated before the entry is written.

Example

Record a preference change by placing the tag on the page your marketing preferences form returns to after a successful submit, such as /preferences-saved. The tag runs each time that page renders, so use a page that only a successful submit leads to.

```liquid

{% audit_event “marketing_preferences_changed”, message: “Customer updated marketing preferences” %} ```

The entry appears on the Audit Log list with Event Type custom and Custom Event Name marketing_preferences_changed.

Was this article helpful?

Was this article helpful?