If you have already enabled a scenario, changing it may cause the Scenarios module to lose information about any site visitors who are currently progressing through the scenario. For example, assume you have enabled a simple scenario with one segment that watches for visitors in a given profile group to log in, waits two weeks, and then sends them an e-mail reminding them to log in again. A site visitor called Jim, who belongs to the specified profile group, logs in on Monday. The next day, you decide to make some changes to the scenario. Depending on the nature of the changes you make, the Scenarios module may be unable to “move” Jim from the old version of the scenario to the new one. Its knowledge of Jim’s current position in the scenario (his scenario state) may be lost, and Jim may be removed from the scenario before he has progressed to the end.

When you make a change to an enabled scenario segment, you can check to see whether the type of changes you have made will cause the system to remove any visitors who are currently progressing through it.

In general terms, changes that you make to a scenario can be classed as either “topographical” or “cosmetic.” Topographical changes are those that involve making major changes to the structure of a segment, for example by adding or removing new elements, in particular forks, branches, and “Waits” elements to the beginning or middle of a segment. (However, adding a new element to the end of a segment does not disturb the topography of a scenario and does not cause visitors to be removed from it.)

Cosmetic changes usually involve changing only the details of a specific element. For example, if a segment includes a Visits element and you change only the name of the specific page within that element, you have made a cosmetic change.

Usually, topographical changes require the system to remove visitors from scenario segments, but cosmetic changes do not.

Notes: When you use the Verify Changes option, the system does not check whether any site visitors are, in fact, currently progressing through the scenario. It simply verifies the type of changes you are planning and alerts you to their possible effect.

The system performs the same check when you attempt to save changes to an enabled segment, regardless of whether you have used the Verify Changes option. If your changes require the removal of site visitors, the system displays the following message: “Data for the current participants will be discarded and the scenario will be restarted. Proceed?”

Only information about the visitor’s scenario state is lost. If the system has already made changes to the profile database as a result of the scenario elements through which visitors have already passed, it keeps these changes. For example, assume you have a scenario segment that performs content targeting by watching for visitors to visit a given page, updating a profile property called “Confidence Index,” and then displaying appropriate content on the site’s home page. If you make a major topographical change to this segment (for example, you add a fork), the system will remove any visitors who are currently moving through this segment. However, if any visitor has progressed past the element that changes his or her profile property, the change is not lost when the visitor is removed.

The Verify Changes feature does give you some valuable information about the effects of your changes to a given scenario segment. However, it is still very important to take care when you edit an enabled scenario, and to minimize this activity whenever possible. Visitors whose scenario state is lost can progress through the scenario again if they meet the criteria that trigger the scenario’s elements. This behavior may have undesirable results; for example, if you use Commerce and you have a scenario that e-mails discount coupons to site visitors who perform specific actions, you may accidentally send the coupon twice to the same visitor. In addition, any data that you collect for reports may be distorted if you accidentally allow visitors to pass through a scenario twice.


Copyright © 1997, 2016 Oracle and/or its affiliates. All rights reserved. Legal Notices