Reusable Triggers

The Reusable Trigger feature in SiteSpect allows you to define and save trigger conditions that can be applied across multiple campaigns and components.

Reusable Triggers replace the older "Page Categories" functionality, providing more flexibility and reusability in your experimentation workflows.

A trigger is a set of conditions that determine when to make a change or measure something. Triggers are used on campaigns, global changes, metrics, and more.

 Creating a Reusable Trigger

  1. Navigation:

    • From the SiteSpect dashboard, select Components from the left-hand navigation.
    • Click on Triggers under Components, then click Create to start defining a new Reusable Trigger.
  2. Trigger Definition:

    • Name: Enter a descriptive name for your trigger that clearly conveys its purpose. For example, "Product Page Trigger" or "Mobile Users in US."
    • Description (optional): Provide additional details or context about the trigger’s purpose or use case. This can help other team members understand the trigger’s role within campaigns.
    • Tags (optional): Add tags to categorize and easily search for this trigger later. Tags can be particularly useful for organizing triggers by project, campaign type, or other relevant criteria.
  3. Preview:

    • URL Preview: You can enter a URL to see how your trigger logic applies to a specific page. This helps you validate that your conditions will match the intended pages or requests.
    • Get Link: This option allows you to generate a shareable preview link, including the ability to Scan with a QR code for easy previous on mobile devices.
  4. Method:

    • Server Side: Select this option if your trigger should be evaluated on the server, typically used for traditional websites and multi-page applications (MPAs).
    • Client Side: Choose this if your trigger should be evaluated in the browser, commonly used for single-page applications (SPAs) and progressive web applications (PWAs).

Available Trigger Types

Server-Side Triggers

These triggers are evaluated on the server and are typically used for traditional websites and multi-page applications (MPAs):

  1. URL Path:

    • Matches a specific URL path, ignoring the host name. For example, you can trigger on URLs like /products, /checkout, or /about-us.
  2. URL Parameter:

    • Targets specific parameters within the URL query string. For instance, if your URL is www.example.com?page=3, you can set a trigger for the parameter page=3.
  3. Page Source:

    • Triggers based on the presence of specific HTML or other content within the page source code.
  4. Geo Location:

    • Continent, Country, State, City, Postal Code: Triggers based on the visitor’s geographical location. For example, you can create triggers for visitors from specific countries, cities, or even postal codes.
    • Bulk Postal Codes: Allows you to upload a list of postal codes to trigger the campaign in specific areas.
  5. HTTP Header:

    • Custom: Define custom header values to match.
    • Referrer: Trigger based on the referrer URL from where the visitor arrived.
    • Cookie and Set-Cookie: Use cookies set in the visitor's browser to trigger campaigns.
    • User-Agent: Target specific browsers or devices by identifying the user-agent string.
    • Host, Protocol, Method, Response Code, Content-Type, Accept-Language, Content-Language, Date, Location: These options allow for precise control over when a trigger is activated, based on various HTTP headers and their values.
  6. Request Payload:

    • Triggers based on specific content or values within the request payload, typically used for POST requests.
  7. Visitor Behavior:

    • Triggers based on specific behaviors or actions taken by the visitor, such as page views, click actions, or session data.

Client-Side Triggers

These triggers are evaluated in the browser and are ideal for single-page applications (SPAs) and progressive web applications (PWAs):

  1. URL Path:

    • Matches a specific URL path, ignoring the hostname, hash, and query parameters. For example, you can trigger on URLs like /products, /checkout, or /about-us.
  2. URL Parameter:

    • Targets specific parameters within the URL query string. For instance, if your URL is www.example.com?page=3, you can set a trigger for the parameter page=3.
  3. URL Hash:

    • Targets the fragment identifier in a URL (the part after #). This is useful for pages that change content dynamically without a full page reload.
  4. URL Hash Query:

    • Matches specific parameters within the URL hash, commonly used in SPAs to track states or actions on the page.

Audience Types Supported as Triggers

In addition to the standard trigger types above, you can also use specific audience types as triggers. These audience types allow you to refine when and where your variations are applied: Data Sets, Time, and Mobile.

Using Reusable Triggers

Reusable Triggers can be applied across various components in SiteSpect, streamlining your workflows and ensuring consistency:

  • Campaigns:

    • Apply Reusable Triggers to campaigns to consistently trigger variations based on predefined conditions, such as specific URLs or visitor behaviors.
  • Metrics:

    • Use Reusable Triggers to consistently define when metrics should be captured, ensuring accurate and uniform data collection across different campaigns.
  • Factors:

    • Apply Reusable Triggers to factors within campaigns to ensure that modifications are consistently triggered under the same conditions, making it easier to manage and reuse logic across campaigns.
  • Global Changes:

    • Deploy Reusable Triggers in global changes to trigger site-wide modifications under specific conditions, maintaining consistency across your site.

By reusing triggers in these areas, you enhance efficiency and ensure uniform application of conditions across your testing and personalization efforts.