|Catching Exit Traffic|
How to determine the users exiting the buying process
A client of mine has an asp site that sells something that involves a 5 step process
Step 1, ask for Email address, Postcode
Step 2, ask for Specifics,
Step 3, Show Something Price, get Personal Details
Step 4, Payment Methods
Step 5, Send order to client via email, Show Thanks to user
The client is seeing alot of traffic but not enough sales. He would like the ability to contact people who have got to Step 2,3 or 4, but have not continued to Step 5.
I need to be able -
1)Determine the users who have exited the buying process at Steps 2, 3, or 4 (Not simply exited the page) who have not gone to Step 5.
2)Send the collected info gathered so far to client.
Can anybody give me pointers as to where to start/how best approach this.
Thanks in advance.
A few ways to do this, heres one way -
First you need to store the visited pages of each session in a session variable such as an array of strings, or persist them to a db/text file etc.
When the session ends (session_onend() event), check the array for certain pages to determine if they backed out of a sale. You will need a custom find function e.g
if myFind(arrPages(), strPurchase1URL) and
If true, then fire off an email.
If you go this route, I would build a proper list class and search method based on this:
The above gives me something to start on. I need to extend my limited asp knowledge to learn about Sessions.
Does the session_onend() event reliably fire on abort? Does it fire immediately or does it default to 20 mins?
There has been a lot of discussion in the past on the reiability of session_onend() , it does default to 20min, although it can be changed.
Generally I have found it reliable.
You will need to check specific the version of IIS for more info on these points.
If it is unreliable on your server, you can still accomplish the same result by running a script periodically - scheduler/cron job, but you will need to store the urls and user data in a db/text file or applicaton level variable.
Think I'll leave this until after the Christmas break...Cron Jobs, writing to dbs, lots of testing, sounds more than a couple of hours I predicted.
Happy Christmas in the meantime