Open topic with navigation
Visitor Context enables marketers to deliver personalized content to site visitors through context-based rules that automatically place visitors into groups based on browsing behavior.
Use Visitor Context options to create rules that add anonymous or authenticated users to named groups based on referring URL, search terms used, IP address, or browser attributes. You can then conditionally render what visitors see based on group membership, as you can with other CommonSpot groups. See the CommonSpot demo site and the Demo Site Guide for good examples and explanations, respectively, for using Visitor Context features.
Note that these groups are completely separate from other CommonSpot groups and cannot be handled the same way. For example, you cannot directly assign ownership or site, subsite, page or element security to any individual Visitor Context group. You can only add Visitor Context Groups to existing Groups.
Use this feature to display selected events to only those users who browse similar events, or serve targeted offers to visitors whose referrer address or search terms indicate interest. Visitor Context does not generally apply to contributors.
To serve context-based content :
Like all groups, Visitor Context groups are stored in the Users database and are shared across all sites associated with a given Customer. (See Databases and Manage Companies for more information.)
Note that while Visitor Context rules are defined within an individual site, the groups they target span all associated Customer sites and can affect content in any of them. For example, a rule triggered by accessing a pay-per-click landing page could add visitors to a group that schedules the display of a related banner across multiple sites. Be aware that although this powerful feature can be used to your advantage, it can also produce unintended results.
Also note that all group names must be unique. You cannot create a Visitor Context group with the same name as an existing standard CommonSpot group, or vice-versa.
You cannot view, add, or remove visitors from context groups manually. Membership is assigned automatically based on the rules you create for:
You can make rules temporary (apply per-session or for a specified number of days) or permanent (non-expiring). Each rule remembers whether it is temporary or permanent. For rules with memory beyond the current session, CommonSpot sets a cookie to track that the rule was triggered, and when the visitor returns to the site at a later date, puts them back in the specified group, whether their behavior matches that rule again or not. For example, visitors referred from a jobs site and assigned to the Job Seekers group remain in that group on subsequent visits, regardless of whether they return via a jobs site.
(Remember that, because cookie tracking is browser-based, rules triggered in one browser affect activity for that browser only. Also note that since Visitor Context rules are designed for anonymous site visitors, with no user records in CommonSpot, triggering a rule has no effect on any CommonSpot databases.)
CommonSpot includes an option to create custom rules to evaluate conditions not addressed by standard rule options. To create custom rules, you must first create a CFML file in a location that can be referenced as a cfmodule template path, then create a visitor context rule with the condition "Is recognized by this custom module" pointing to your custom module.
Modules test whether the conditions you've defined are met, and return a true or false boolean value indicating whether to trigger the rule.
This feature also allows you to reuse the same module in multiple rules, while causing it to behave differently in each one.
See Add Visitor Context Rule for details.
Once you create a rule you can activate it, deactivate it, or delete it:
When rules are active, CommonSpot checks for the triggering event at the appropriate times. When it occurs, CommonSpot adds the visitor to the specified group, and optionally sets a cookie to remember the event on future visits.
When rules are inactive, the triggering event is no longer checked, so no new visitors are added to the associated group, and no new cookies are set; however, visitors with existing cookies are returned to the specified group when they come back to the site. Setting rules to this state is useful for preparing for a later campaign or when temporarily suspending campaigns.
When rules are deleted, associated events are no longer checked, and any existing cookies are ignored.
Out of the box, Visitor Context Rules recognize external search terms from Google, Bing, and Yahoo.
If the shipped set of search engines doesn't meet your needs, you can define your own through the CommonSpot API. This might be valuable if you work in an industry where another specific search site is very important, or if you use a hardware search appliance on your site, rather than the built-in CommonSpot search elements.
See the documentation for the SearchEngine API component for more information.
You can download PDF versions of the Content Contributor's, Administrator's, and Elements Reference documents from the support section of paperthin.com (requires login).
Sites upgrading from versions earlier than release 6.0 should review the following (from the support section of paperthin.com - requires login):
For technical support:
Open topic with navigation