[ic] Discounts and coupon tracking?

Paul Jordan paul at gishnetwork.com
Thu Jun 3 14:13:20 EDT 2004

Jonathan Clark [jonc at webmaint.com] wrote:
>>>   Thoughts on associating and tracking a code with a particular
>>> item?
>>>   [discount] and [item-discount] will show me the change in values.
>>> However, I'd like to track a code/value with this and log with
>>> transactions.  In some basic testing it doesn't appear that session
>>> will track using an associative array / hash.
>>> Something like ...
>>>   1) user enters coupon number
>>>   2) lookup number in a coupon table
>>>   3) if active, apply discount
>>>   4) store discount code/valuey persistant means
>>>   5) at checkout verify discounts and log transaction
>> I am attempting do a similar process.  I need to give out coupons
>> based on previous orders and discounts offered to individual
>> customers. How can I effectively track the coupon and personalized
>> amount of the coupon for orders?
>> Any recommendations would be appreciated.
> I am working on a coupon system at the moment. Here is what it can do
> so far:
> Discounts (amount or % off):
>  All items
>  Entire order
>  Single item
>  Single item, auto add a qty to cart
>  Shipping (if I can work out levies)
> Constraints:
>  Apply only if order/item over $x
>  Date range
>  Max uses (allow to be used x times only, then disable)  Apply only
>  to zzz affiliate. Apply only to specific user.
>  Disable coupon entirely

Hi Jon

I have a system similar to this. I had it built a while back, but since have
become pretty decent with perl, so will be rewriting it myself. I rewrote some
of it a few months ago out of necessity.

One thing I currently rely on is querying 'transactions' for checking usage. I
think I will be making a additional dicount_log table which would provide for
applying/limiting/marketing purposes.

Another thing I can say is it kinda "feels" like IC is headed for default SQL
db, so don't be afraid at utilizing it's power.

You mentioned ..."Apply to one specific user". I recently needed to apply
similar discount for 10 customers. This was kinda clumsy, as they were all
single use. I ended up making 10 coupons for them. When I rewrite mine, I think
I allow a field to insert multiple usernames into. So a TEXT field that you can
insert 50 names into, then check against the discount_log table as each user
uses theirs.

OK, So if Kevin Walsh reads this, I must revise my plan. He wouldn't talk to me
anymore if I placed many id's into a TEXT field. I think I should just extend

discount_id		username		order_number	date_used
00230			halleberry		028422		20040316

This would extend you schema to allow one coupon (and its definitions) to be
applied to many people. You could mulipart-key the above (discount_id,
username) to disallow accidental duplicates.

> Tracking/reporting:
>  campaign
>  salesman
> I would like to do..
>  Apply discount only up to $y
>  Constraint based on item option (allow only for a,b,d / don't allow
> for a,b,d)
> ..but I don't think IC's current discount system will support this.
> I am also building in some fields for gift cert use (this is
> basically a coupon where the value decreases rather than the
> quantity. Oh, and probably a random code generator at some point too.
> (eg. create me 1000 coupons of this type)

Kevin has a random generator for your "code generation" needs:


> I am putting it in a usertag which would be called in two places -
> when the code is entered, verified and applied and when it is redeemed
> (log_transaction, needed where the qty/value gets downdated).
> In your case, the coupon would be a one-shot (max uses=1) and for a
> specific value. It could also be constrained to a particular username.
> Comments welcome..
> Jonathan.

On thing to beware of is this coupon will be applied most probably near
checkout. You will have to devise a "intuitive and apparent" plan to deal with
those that find a way to continue to shop after they have been to your discount
code app. They could back out and remove items and circumvent your "qualifying
amount". You can just recheck it at checkout once again, but if it is not
apparent, a user might think you bait & switched them... "Hey the coupon
disappeared when I actually checked out"...

Maybe when coupon is applied, set a scratch. then in your top master template
have a

[if scratch coupon_applied]
	[tmpn coupon_applied][/tmpn]
	[if !scratch checkout_pages]
		<br> Notice, Your coupon has been UNAPPLIED.
		This is beacause.....
		To continue....

That should have very little overhead on all regular pages. Just set
	[tmpn checkout_pages]1[/tmpn]
above the template call in your safe checkout pages to keep the coupon intact.


More information about the interchange-users mailing list