purchaseID Size Limit
The purchaseID variable has a different size limitation than most of the other variable. Where most of the other variable in Site Catalyst can have 100 bytes, the purchaseID is limited to 20 bytes or less, and must be standard ASII. The following code shows example of the purchaseID variable.

    s.purchaseID=”11223344”
    s.purchaseID=”a8g784hjq1mnp3”

EVENT SERIALIZATION (KEEPING EVENT UNIQUE)
While on the subject of keeping events from being falsely duplicated, you also need to know how to keep ANY of the events from duplicated. This is called “event serialization”. As discussed above, the purchase event has its own variable for serialization. However, event serialization applies to any conversion events. Event serialization is very useful in the following instances.

- A page may be reloaded or refreshed, which repeatedly sends an event to Site Catalyst. Event serialization prevents events from being recounted by using a “serial number” for each event.
- The user saves the page to his/her machine for later review-a scenario that is quite common on purchase confirmation pages to review purchase receipts. Event serialization prevents the subsequent page reloads from re-counting events.

The following code example shows how to implement event serialization.

    s.events=”event1:123456789”

In this case, the value “123456789” causes the event to only be counted once. Any other attempts to pass the value in will be recognized and not counted in the reports to prevent duplication. If s.events only contains a value of “event1” the value could be passed multiple times and falsely inflate the numbers in the reports.

This functionality is not used as often for non-purchase events, because you have to create and maintain a unique list of IDs to be used for this purpose. The cost and hassle of doing this may override your need to avoid a few extra registrations being counted by reloads (for example).

VISITOR PROFILE INFORMATION
The state and zip variables are conversion variables. They are similar to eVars in that they capture events, but unlike eVars, they don’t persist.

Since the state and zip variables expire immediately, the only events associated with them are events that are fired on the same page on which they are populated. For example, if you are using state to compare conversion rates by state, you should populate the state variable on every event page of the checkout process.

For e-Commerce sites, Omniture recommends using the billing address as the source for zip code, but you may choose to use the shipping address instead (assuming there is only one shipping address for the order) There are no limitations on the state variable outside of the standard variable limitations (100 bytes, ASCII 127, etc). Example of the state and zip variables are shown here:

State
   s.state=”california”
   s.state=prince edward island”

Zip
   s.zip=”94116”
   s.zip=”92806-4115”

As you can see, event though these variables are called “state” and “zip” there is no reason that you have to put only US-centric information in them. You could put ANY value in them, and it would relate to the event that was called on the same page.

The values that you populate into the Zip report will show in the Conversion > Visitor Profile > Zip/Postal Code reports. Likewise, the values that go into s.state variable will show in the Conversion > Visitor Profile > States. Without populating these variables, the associated reports will be empty.