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 Visitor 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`
Updated 5 months ago