In general, templates allow you to write content with placeholders for particular values that may change based on who will be reading the final version of the content, or the context in which the content is to be taken.

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`