Before proceeding further, we need to establish a way of identifying visitors to our site and of keeping track of them as they move from page to page. Once visitors buy something, they become customers with purchases, and we need to be able to association particular customers with particular purchases. We'll look at a couple of ways of assigning unique identifiers to visitors and a couple of ways to keep track of them.

Generating Random Numbers

One method of producing a unique identifier is by generating a random number. In PHP this is done with code in the following format:

The min and max are integer values that define the range of numbers within which the randomly generated number should fall. The result is assigned to variable RandomNumber. Thus, if we wished to generate a number between, say, 1111111111 and 9999999999, we would use the statements,

In this case, we've assigned the random number to a variable named OrderNo, the reason being that if this visitor decides to purchase something, we'll use this number as the order number. There's always the chance, however small, that the number generated is the same as an order number that already exists. So, to be safe, the number should be checked against previously issued order numbers before assigning it to the visitor.

Previously issued order numbers will appear in two places. They will be stored in a shopping cart table for visitors who are currently shopping; they will be stored in an orders table containing customer information from previous sales. We haven't yet discussed these tables, so we'll wait until we cover these topics before considering the check for duplicate order numbers.

So, where do we put the OrderNo generator routine? Probably on the opening page (home.php) of the site since we'll want to start tracking visitors immediately on their arrival. Doing this anticipates that we might wish to track the meanderings of visitors at our site even if they don't purchase anything. We won't be doing that here, but it's a possibility.

Tracking Customers with Query Strings

There is a slight problem to be dealt with, however. Every time the visitor returns to our home page a new number will be assigned. What we'll need to do is check to see if an order number already exists for this visitor and, if so, not to generate a new number.

Recall from previous discussions that in order to keep information alive from page to page we can use query strings to pass that information. We previously illustrated the use of a query string to pass search information to and from the search.asp and detail.asp pages. The same thing can be done with the OrderNo. We can pass it as a query string from page to page in order to keep it alive and, in solution of our current problem, to have a way of knowing that an order number has already been generated.

Every page at our site will need to receive a query string containing the OrderNo along with any other information we happen to be passing to that page. Since the home.asp page will also be a recipient of an OrderNo query string (when visitors return to the home page from other pages at our site), we can check for the presence of this query string for evidence that an order number has already been assigned, and bypass the order number generator routine.

All of this explanation reduces to some very simple code. We enclose the random number generator routine inside a test for a query string value:

<?php

if ($_GET[OrderNo]) == "")
{

  $OrderNo = rand(1111111111,9999999999);

}
?>

If our home page receives a query string with a null OrderNo, then a new order number will be generated. This will happen the first time a visitor accesses our home page since no query string is initially passed to our site. However, if our home page receives a query string witha non-null OrderNo (a number exists), then the routine is skipped. This will happen on all subsequent returns to our home page from any other page on our site.

Of course, if a visitor leaves our site and returns, a new number is generated since the external site doesn't pass an OrderNo query string. This situation causes severe problems in keeping track of customer orders. If the person has already added items to their shopping cart under one number, and then leaves and returns, there is no convenient way to know that this is the same person adding new items to their shopping cart. In effect, the first round of product selections is lost.

You can get around this problem by requiring all visitors to log on to your site and assigning permanent customer numbers that they use during all visits. Then, the customer number always attaches to that same person. This is not a bad idea, but requires more elaborate coding than we wish to deal with here. A better solution for present purposes is to tie the order number to the Session Object.

Using Sessions

Under PHP, visitors to a Web site establish "sessions." A session is automatically established when a visitor first arrives at any page at the site; a session is automatically terminated when the visitor fails to access a page within a 20-minute time limit. So, a session begins when the visitor arrives; it ends 20 minutes after the visitor leaves. This 20-minute time limit also permits the visitor to leave the site and return later without being considered a new visitor. (Incidentally, this 20-minute time limit can be extended if deemed necessary. We won't do so for our purposes.)

Associated with this visitor session is the $_SESSION[] associative array. You can think of the $_SESSION[] as a global storage area where information pertaining to a visitor is maintained. All visitors at a site have their own individual Session Objects for keeping track of individual activities. As you might suspect, then, a visitor's Session Object might be a good mechanism for keeping track of customer orders as the person navigates from page to page and off-site and on-site. If a value such as an OrderNo is placed into the visitor's Session Object when they first arrive at a site, that value is available from any page; it is not necessary to drag the value from page to page with a query string.

Session IDs

PHP keeps track of visitors through a unique identifier it assigns when a session is established. This unique value is maintained as the session_id() property of the Session Object. You can access this value after starting a new session:

<?php

session_start();

$_SESSION[OrderNo] = session_id();

?>

The session_id() function automatically generates a session id. If you prefer to create your own random id, we can use the rand() function to generate a value and then store it in a session variable:

<?php

session_start();

$_SESSION[OrderNo] = rand(1111111111,9999999999)

?>

Returning to the issue of assigning unique OrderNo values for new visitors to our site, and the issue of keeping track of that number from page to page, we can use a session variable to easily accomplish these things. The notion is this: When a visitor first arrives at our site, we'll assign the session_id() (or randomly generated ID) as our OrderNo; and, in order to make this number available to all of our pages, we'll store it in the $_SESSION[] where it will remain until 20 minutes after the visitor leaves our site. Of course, when our visitor chooses to become our customer and finalizes a purchase, we'll simple "destroy" that session using session_destroy() so that a new session is established with a different order number.

Tracking Customers with the $_SESSION[] array

So, let's apply all this to our need to assign a unique ID (an OrderNo variable) for our visitors, and the need to keep this number alive as the visitor moves from page to page.

The session id value is now acessible on subsequent pages for tracking and identification purposes. It can be acesssed using $_SESSION[OrderNo]. The following example shows how the value would be retrieved and displayed on a second page:

It might appear as if this technique would be the only reasonable way to maintain state between pages. However, there are potential problems. For example, if, during a visit, our customer is inactive for a period of 20 minutes, then PHP automatically ends the session and we have no way of recovering that person's activities. This could happen, for instance, if the customer is called away to the phone, gets distracted by a different site, or just falls asleep. An entire new session would be established when they returned and we would have to figure out a way to delete all pending purchase items since there is no way to complete previous transactions.

So, you'll need to balance the efficiencies of using sessions against the inconveniences of abandoned sessions. Still, it might be a reasonable assumption that most visitors will not be inactive for 20 minutes and that the scripting ease of using the Session Object overrides other considerations. As noted above, you can always change the 20-minute timer if it appears too short.

Visitor IDs versus Order Numbers

In the previous example, we've assigned order numbers to visitors, both as a method of uniquely identifying visitors and, eventually, to uniquely identify their sales orders. We're somewhat assuming that all visitors become customers.This is not an issue if we're going to use random numbers for both purposes. However, a company might have a more systematic way of assigning order numbers. Order numbers might, for example, be chosen from a sequence of pre-established numbers. If so, then an order number assigned up front leaves a gap in the order number sequence for a visitor who does not become a customer.

If this situation exists, then you'll need to assign a random number up front as a "visitor number" to keep track of this person's meandering through your site; and you'll need to assign a final "order number" when the commitment is made to purchase. From what we see on the Web, order numbers have no apparent logic to them, in which case you can use the same number to track visitors and to identify their orders.