Creating Lightboxes

Lightboxes pose a way to present additional information to your users after a certain event or trigger.

In the context of Bunting, good uses for these tools are to create brand awareness (such as promoting a featured item specifically), reiterating unique selling points (such as the number of 5 star reviews), gaining feedback via forms, and encouraging sales via promotions.

Continue reading Creating Lightboxes

Adding a coupon to your website

Adding a coupon to your website

Coupons are a great way of raising sales, particularly when combined with a ‘limited time only’ message. However you can run into problems when visitors try to use coupons that have expired, or pass them on to their friends to use. Bunting can help you avoid these problems with its *|COUPON|…|* function. This function takes your coupon and disguises it. It creates a unique replacement coupon code that your visitors see, and hides your original. When the visitor then enters their replacement coupon, Bunting checks to ensure the coupon is in-date, and is being entered by the visitor who it was given to. Providing everything checks out, Bunting then privately swaps the replacement coupon with your original, real coupon, for your site to process.

Continue reading Adding a coupon to your website

How priority affects visitor segments

How priority affects visitor segments

Many actions in Bunting, such as lightboxes, header bars and website exit confirmation messages, are single instance actions. This means that two of the same type of action cannot load in one page view by a visitor.

For example; Say you have defined two visitor segments. One activates a lightbox containing an promotional message, the other activates a lightbox containing a feedback form. If a visitor matches the criteria of both visitor segment conditions then Bunting will have to choose between which lightbox to load, as it cannot show both in the same page view. This is where segment priorities come in.

Continue reading How priority affects visitor segments

Adding a Countdown timer to enhance time sensitive offers

Adding a countdown timer to enhance time-sensitive offers

Time sensitive offers are one of the most powerful ways to give your sales messages impact. They increase urgency and promote greater impulse purchasing.

Adding a countdown timer to your website would normally be tricky job for a programmer. However Bunting makes it easy for anyone to do it. Whether in a lightbox or as part of a targeted banner, countdown timers can be added anywhere on your website. The syntax to add a countdown timer is as follows:

Continue reading Adding a Countdown timer to enhance time sensitive offers

Guide to Merge Tag Conditional Statements

Conditional statements allow you to easily implement basic logic into your behavioural targeting actions and webpage widgets. This will allow you to harness greater control over what appears to your website’s visitors.

Let’s say you have a lightbox, an email, or a banner, that will appear to a certain group of visitors. You may want to personalise that lightbox by including the name of each visitor at the top. To do this you would use a replacement tag, like so:

Hello *|FORENAME|*, here’s a special offer for you…

Continue reading Guide to Merge Tag Conditional Statements

Adding a Countdown Timer to an Email

Adding a Countdown Timer to An Email

When creating behavioural targeting emails you can add a countdown timer to add urgency. To do this, amend the field ‘Countdown’ with one of the following values:

  1. A numerical value between 1 and 8765 represents a countdown in hours from the time the email is sent. 8765 is the number of hours in one year, thus one year is the maximum timer of this type. This timer starts relative to when each email is sent.
  2. Any numerical value above 8765 represents a Unix Timestamp. A Unix Timestamp is a 10-digit number that can be used to identify any time to a precise second. Say you wanted all recipients to see the same countdown to a specific date and time (such as mid-night on New Year’s Eve) you would use a timestamp. This website will let you easily create a timestamp to your needs.
  3. The word ‘midnight‘ will set the countdown to midnight of the day it is loaded.

Getting a dynamic value from your website

Getting a dynamic value from your website

There are times when you may wish to include dynamic content that your website recognises into Bunting actions. Examples include time-sensitive discount codes, unique for every visitor, within banners, lightboxes and cart abandonment emails. To do that you can insert GET calls.

GET call syntax

The syntax you enter into an action, to perform a GET call to your server, is as follows:

*|GET|web address|alternate content|cache expiry|*

The first parameter – web address – is mandatory. This is the address of a script, typically located on your website, that will generate a value such as a discount code, save it to your website’s database, and output that value via HTTP for Bunting to collect. The output from your website must be isolated purely to the value you want Bunting to give to your visitors. Do not include HTML of any kind, unless this too is intended for your customers. If the value is sensitive (such as a money-off discount code) then we recommend you protect the page by including a query string such as ‘password’ for your system to validate. For example:

http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j

The second parameter – alternate content – is optional. This is alternative content that will appear to your customers should your server be unreachable. In the latter example you may want to enter a generic discount code, so that if your server cannot be reached to provide the customer with a unique discount code, then that generic discount code will instead be provided. If your server cannot be reached and you choose not to include any alternate content then the GET call code will simply be removed, and your customers will see nothing.

The third parameter – cache expiry – is also optional. When a GET call is performed the value returned from your script (located at the web address you entered) is cached within Bunting. This markedly improves loading speeds for your customers’ benefits, and reduces processing on your server. During the cache lifespan your server is not called and the cached value is used instead. Expiry of a GET call cache doesn’t mean that the value will no longer be displayed to the visitor, it simply means that Bunting will again contact your server for the value (a slower process), then re-cache the result. In 90% of cases you won’t need to pass a value for this third parameter. If you don’t then the cache lifespan is set as the default 30 days, unless the GET call is inserted into an action that also contains a countdown timer, in which case the cache expiry will automatically be set to coincide with the expiry of the timer. Although it’s unlikely you’ll need to, you can override the default cache expiry behaviour by entering your own expiry period value as the third cache expiry parameter:
1) A numerical value between 1 and 8765 represents the expiry in hours from the time the GET call is first performed. 8765 is the number of hours in one year, thus one year is the maximum of this type. This expiry starts relative to when each visitor sees it. If visitor A first sees the GET call 10 minutes before visitor B, then their cache will also expire 10 minutes earlier.
2) A Unix Timestamp; a 10-digit number that can be used to identify any time to a precise second. Say you wanted all GET call cached values to expire at a specific date and time (such as mid-night on New Year’s Eve) you would use a timestamp. This website will let you easily create a timestamp to your needs.
3) The word ‘Midnight’ means the cache will expire at midnight of the day it is called.

Important syntax notes: All three parameters must be separated by|pipe|symbols|. The word GET must be in capital letters. If a second and/or third parameters are added then the two or three parameters must be separated by commas with no spaces. All three parameters must be surrounded by brackets.

Returned values can only be 250 characters, or less. Values generated by your server greater than 250 characters in length (including any HTML characters) will be cropped to just 250 characters.

You can only include one GET call per Bunting action.

Examples

Say you wanted to add a unique discount code for each visitor, with a fallback value of ‘10-OFF‘ should your server not respond, your GET call may look something like this:

*|GET|http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j|10-OFF|*

For the same call, without a fallback value, your GET call may look something like:

*|http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j|*

For the first call, with a cache lifespan of 4 hours (meaning, your server is not called for another 4 hours from the time the first GET call is performed per visitor, your GET call may look something like:

*|GET|http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j|10-OFF|4|*

The visitor_id and action_id URL Parameters

For every web address you enter in a GET call, Bunting appends two URL parameters of ‘visitor_id‘ and ‘action_id‘. The visitor_id parameter contains the ID number of the profile in Bunting that is associated with the visitor who has triggered the GET call. For example, the command:

*|GET|http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j|*
would actually call the following address on your server:
http://www.your-website.com/discount_code_generator.php?password=7hSDjd63j&visitor_id=12345&action_id=9876
when the parent action is triggered by a visitor to which Bunting has assigned ID number ‘12345’

Whereas with a visitor with the ID number ‘456’ :
*|GET|http://www.your-website.com/password_generator.php|*
would call:
http://www.your-website.com/password_generator.php?visitor_id=456&action_id=9876

The action_id parameter is the numerical reference of the action in Bunting that is calling your server (such as a lightbox, a header bar, an email, etc).

Your website’s response script could ignore both these values, or optionally choose to use and save them in order to remember which values it has already generated and for who. You could, for example, use the values to ensure uniform behavior; so that every visitor only receives the same code that is unique to them, rather than being given a new code every time they trigger the action containing the GET call. This, however, isn’t relevant if the third cache expiry parameter is set to cover the lifespan of the discount code.

Cache values relative to visitors

Cached CALL values are made uniquely for every visitor who triggers an action containing a GET call. For example; two GET calls made within the cache lifespan for two visitors, will call your server twice and cache both those values. On the other hand, three calls made within the cache lifespan for just two visitors will call your server only twice, caching both values, and recalling a previously cached value once.