Templates are used to dynamically insert content into text placeholders. These are used in our Schemas and in our Automation and Triggers.

There are two main uses for Woopra templates:

• Determining how an event looks in the visitor profile (i.e: "Viewed Page /docs" instead of "Did pageview").
• Using event and visitor properties in the configuration of an automation like a trigger, for instance when sending a text message or transactional email in which you want to include a visitor property like the person's name, or an action property like the url of their abandoned cart.

The Templating System

Woopra templates use the ${ and } format for template expressions. In general the format will be:
${<SCOPE>(visitor|action|visit).<property name>}.

The available scopes are visitor, action, and visit. The visitor scope means visitor properties like a visitor's first_name. The Action scope means action/event properties, like the url of a pageview event. The visit scope has session level properties such as browser or ip.

Templating Values

The SCOPE part allows you to declare if you are referring to a session/visit property, a visitor property, or to an action property of the current action (in the case of a trigger, this would be the action that is selected in the "trigger when" section when you define your trigger.)

To see what action properties are available for a given action, it is best to go check out your event schemas in the Woopra interface: Configure > Action Schemas. Similarly, you can see what properties/fields you have defined in your schemas for visitors in Configure > Visitor Schemas.

A visit scope allows you to use a visit property which actually applies to many actions. For instance things like: ip address, referer/source, Operating system, browser, etc. are all visit properties and can be accessed in templates using, e.g.: ${visit.browser} For more on the visit scope and properties, see Visits and Tracking Visit Properties, and finally Generated Visit Properties which discusses a few properties like browser that are generated automatically when possible, and generally available in any templating situation. They are not always present, however. For example, you wouldn't expect to have a visit.browser on a session that only includes a serverside event like "email bounced" in which the visitor never actively used a browser to interact with your system.

Template Logic

At the moment, template logic is very minimal, but you can submit a feature request to vote more development in this area. For now, you can use AND/IF statement to determine if one value exists and if so to use it, otherwise to use a default value. The format is demonstrated in a couple of example use cases is as follows:

You could send a personal message using Drift or Olark for example like this:
Hello ${#IF ${visitor.name}, Hello ${visitor.name}!, Hi there! ) }

For the Bellgram app, the "Sent a text" event is titled like this in the interface:
Sent A Text to ${#IF ${action.agent_name}, ${action.agent_name} at , ${#IF ${action.customer_name}, ${action.customer_name} at }} ${action.destination_phone_number}'
So this example would say: If the agent_name is on the event properties (which in this case means that the agent was the recipient), say "Sent a Text to Ralph at (415) 555-5555", otherwise, if the customer_name exists, (which would mean that the agent sent the text to the customer) then say: "Sent a text to CUSTOMER NAME at (415) 555-5555`