Here are some things to keep in mind when setting up pricing based on Promo Codes.
- What are the security requirements on the promo code. For example, in some cases a savvy user might be able to see the allowed promo codes by viewing the code of the form.
- Does the client want to accept both Upper and Lower case symbols. Accepting both can be more challenging.
- Do they need to have different prices for different codes.
- How user friendly is it.
Here are 2 examples, showing Pros and Cons of each setup.
Example 1:
- In the following example, without a code, the standard price is charged, and with the code, a reduced price is charged.
| X I will attend the Business of Climate Change Conference on October 15, 2008. |
If you have been given a promo code, please enter it here: _________
Setup:
a. Add the validation expression for the Promo Code box.
b. Add a Price Logic item on the 'I will attend' check box so that the Promo Code value sets the price. Different prices can be set for each valid Promo Code value.
Pros:
a. Has a nice 'feel', since price changes immediately when correct code is entered
b. Multiple Promo Codes can be added, each with a different price associated with it.
Cons:
a. The logic is case sensitive, meaning that it will only validate against an exact match. So if the correct code is 'myCode', then entering a value of 'mycode' in the box will not tirgger the promo code price. Therefore you would usually set all lower case, or all upper case (or just numbers), and then make the validation message warn the user about what case to use. This can sometimes be an annoying problem for users.
Remember also that even if the Validation for the Promo code is set to ignore case (ie: allows both upper and/or lower case), any logic will only match the exact value indicated. The 'ignore case' option in Validations should NOT be used if price logic is being based against that value.
b. Code can be seen on the form. If this technique is used, we need to always review this fact with our client to make sure they understand this point. Often they will say that they can double-check the registrations that come in to make sure no one is cheating. But in some cases, this may not an acceptable solution. So we don’t want them to discover this after the form has been live for awhile, and always want to be up-front with it.
Example 2:
A drop-down or radio selection can be used to set the price based on the selection. When the 'Member with promo code' option is selected, the box to enter the promo code is enabled, and also is required forcing the validation to occur.
O Member
O Non-Member
X Member with promo code
If you have been given a promo code, please enter it here: _________
Setup:
a. Add an Enable logic to the Promo Code box when the 'Member with promo code' is selected.
b. Add a Required validation to the The Promo code box. This only becomes active when the field is enabled (by the logic), forcing the code to be entered.
c. On the Validation screen, add the regular expression in the 'Valid Expression' field to set the correct promo code comparison (see..Validation Expressions for Codes and Promo Codes.).
Pros:
a. Does not reveal the promo code in the source of the page.
b. Case in-sensitive validation codes can be used, since their is no price logic set on the value of the code. So ''myPromoCode222' could be considered the same as 'mypromocode222'.
Cons:
a. Does not allow for different prices based on the value of the promo code.
