This might be a silly idea. But why not create a new table with the one time use codes. Send a url to the customer with the code in the url. When they click on the url, grab this code, lookup the one code in the database and create the actual coupon code for use in the store at that time (or provide a pre-generated one to all users). Sort of a click here to claim your coupon code.
That way you aren't cluttering up the system with lots of coupon codes that aren't likely to be used.
Since this temporary code table isn't used for normal discount functions and can be indexed on the code it should be quite fast. Would need little more than the code and a flag to set when it gets claimed (and any tracking you may want to add)
SUGGESTION: a simple way to generate massive and personalized discount coupons
MVP
Silver Solution Partner
- 5236
- 49485
- 10/4/2010
- Mexico
tarheit wrote:
It is an interesting option
tarheit wrote:
What I proposed creates just one discount coupon that can be personalized and validated for thousands of customers
This might be a silly idea. But why not create a new table with the one time use codes. Send a url to the customer with the code in the url. When they click on the url, grab this code, lookup the one code in the database and create the actual coupon code for use in the store at that time (or provide a pre-generated one to all users). Sort of a click here to claim your coupon code.
It is an interesting option
tarheit wrote:
That way you aren't cluttering up the system with lots of coupon codes that aren't likely to be used.
Since this temporary code table isn't used for normal discount functions and can be indexed on the code it should be quite fast. Would need little more than the code and a flag to set when it gets claimed (and any tracking you may want to add)
Since this temporary code table isn't used for normal discount functions and can be indexed on the code it should be quite fast. Would need little more than the code and a flag to set when it gets claimed (and any tracking you may want to add)
What I proposed creates just one discount coupon that can be personalized and validated for thousands of customers
Team Member
- 547
- 6625
- 12/17/2015
- Armenia
Hello! I need to clarify following for a good answer:
- In what situation these coupon codes are needed? How they differ from existing discount methods?
- How the numbers should be generated who should write the algorithm of their generation.
- Who will be responsible for the troubleshooting if the generated codes would not be validated in nopCommerce?
- Should we limit the number of coupon uses?
- In what situation these coupon codes are needed? How they differ from existing discount methods?
- How the numbers should be generated who should write the algorithm of their generation.
- Who will be responsible for the troubleshooting if the generated codes would not be validated in nopCommerce?
- Should we limit the number of coupon uses?
MVP
Silver Solution Partner
- 5236
- 49485
- 10/4/2010
- Mexico
Sergei-k wrote:
Hi Sergei:
I am rethinking this idea to simplify it with the suggestions that came up in this topic. I will come back within few hours
Hello! I need to clarify following for a good answer:
- In what situation these coupon codes are needed? How they differ from existing discount methods?
- How the numbers should be generated who should write the algorithm of their generation.
- Who will be responsible for the troubleshooting if the generated codes would not be validated in nopCommerce?
- Should we limit the number of coupon uses?
- In what situation these coupon codes are needed? How they differ from existing discount methods?
- How the numbers should be generated who should write the algorithm of their generation.
- Who will be responsible for the troubleshooting if the generated codes would not be validated in nopCommerce?
- Should we limit the number of coupon uses?
Hi Sergei:
I am rethinking this idea to simplify it with the suggestions that came up in this topic. I will come back within few hours
MVP
Silver Solution Partner
- 5236
- 49485
- 10/4/2010
- Mexico
Hi Sergei:
Well after some deep thought, I have redone my suggestion to make it more in accordance with the existing promotions logic and architecture and to make it much simpler to code and to administrate.
To answer your question of “In what situation these coupon codes are needed? How they differ from existing discount methods?”:
• By setting just one code you can have unlimited massive discount codes.
• So it is much easier to set and administrate
• Each customer can get a unique discount code
• Discount codes could be personalized, so they can only be used by the customer to whom it was assigned.
• The code can contain information of who gave it to the user
• It does not affect store performance to have thousands of codes
As you will see the new suggestion is very much in line with the existing architecture and features of the discounts logic.
COUPON CODE SINTAXIS
In the new suggestion the discount code is composed of 2 parts separated by a hyphen (“-“): Code[-Suffix] :
1. Code: is the Coupon Code as it is now in Nop (any text string, but which cannot contain any hyphen). Examples: “ABC1”, “XYZ”
2. Suffix: which is optional is another text string (it is simpler if hyphens are not allowed here either). If there is there is not hyphen present it is assumed that there is no Suffix and for further purposes it will be given value “Null” or “ “. Examples: “123”, “124”, “MM31”, “MM32”. The Suffix might also contain a section to identify the promoter or sales person who gave the code to the user (example Suffixed in the form of “MMnnn” can mean that the codes were distributed by promoter “MM”).
Examples of coupon codes under the new format: “ABC1-123”, “ABC1-MM31”, “JKL” (this does not have a Suffix). So under this logic, for having massive discount codes, the store owner just needs to set one Discount Code and use as many Suffixes as needed.
When the customer enters a discount code:
• The Code will checked against the active Coupon Codes (as it is now handled by Nop) and the corresponding set rules will be applied
• If a Suffix is present, it can be validated by the new set of Requirements described latter.
Thus if the customer enters the code “ABC1-123” the discount will be applied as set for Coupon Code “ABC1”
NEW COUPON REQUIREMENTS FOR VALIDATING THE SUFFIX
Here are some suggestions of new coupon Requirements that can be used to validate the Suffix value:
• “The Suffix must be equal to the Customer_Id of the customer”. This is to have personalized codes that con only be used by the corresponding customer.
• “The Suffix must be equal to the affiliate assigned to the customer. This permits to have codes distributed by affiliates that can only be used by their associated customers.
• The following Restrictions are meant to make it more difficult to hack or falsification of codes:
o “The Suffix must fall within one of the following ranges”. Examples of range(s): MM01-M99; 001-800 or 1Z001-1Z999
o “The Suffix must contain the following text”. Examples of text: “ABC”, “NN”
• “The Suffix must have been assigned to this discount”. This is to assure that the Suffix was previously added to the table of associated Suffixes (discussed later) to the Discount Code. This is a strong check to impede hack or falsification of codes.
NEW DISCOUNT LIMITATION
In addition to the Discount Limitations of “Unlimited”, “N times only” and “N times per customer” include “N times per Suffix”.
ASSOCIATED SUFFIXES TABLE
A new table can be added to make sure that only the Suffixes within it can be used with a Discount Code. It can be updated by:
• Adding/deleting Suffixes individually
• Importing them from Excel
• Or some procedures to generate them automatically:
o Generate N Suffixes randomly of length X and with a prefix of “XXX”
o Generate N Suffixes sequentially, starting with “NNN”, of length X and with a prefix of “XXX”
SUGGESTIONS FOR USAGE HISTORY
• Include the Suffix used in each order
• Add the export to Excel all orders of which used the discount code.
NEW TOKEN FOR MESSAGE TEMPLATES
Include %Customer.Id% in the available tokes so personalized coupons can be sent with certain messages (examples: Customer.WelcomeMessage, OrderPaid.CustomerNotification) like “Here is your personal discount coupon ABC1-%Customer.Id% that will give you a 25% discount in your next purchase”
Well after some deep thought, I have redone my suggestion to make it more in accordance with the existing promotions logic and architecture and to make it much simpler to code and to administrate.
To answer your question of “In what situation these coupon codes are needed? How they differ from existing discount methods?”:
• By setting just one code you can have unlimited massive discount codes.
• So it is much easier to set and administrate
• Each customer can get a unique discount code
• Discount codes could be personalized, so they can only be used by the customer to whom it was assigned.
• The code can contain information of who gave it to the user
• It does not affect store performance to have thousands of codes
As you will see the new suggestion is very much in line with the existing architecture and features of the discounts logic.
COUPON CODE SINTAXIS
In the new suggestion the discount code is composed of 2 parts separated by a hyphen (“-“): Code[-Suffix] :
1. Code: is the Coupon Code as it is now in Nop (any text string, but which cannot contain any hyphen). Examples: “ABC1”, “XYZ”
2. Suffix: which is optional is another text string (it is simpler if hyphens are not allowed here either). If there is there is not hyphen present it is assumed that there is no Suffix and for further purposes it will be given value “Null” or “ “. Examples: “123”, “124”, “MM31”, “MM32”. The Suffix might also contain a section to identify the promoter or sales person who gave the code to the user (example Suffixed in the form of “MMnnn” can mean that the codes were distributed by promoter “MM”).
Examples of coupon codes under the new format: “ABC1-123”, “ABC1-MM31”, “JKL” (this does not have a Suffix). So under this logic, for having massive discount codes, the store owner just needs to set one Discount Code and use as many Suffixes as needed.
When the customer enters a discount code:
• The Code will checked against the active Coupon Codes (as it is now handled by Nop) and the corresponding set rules will be applied
• If a Suffix is present, it can be validated by the new set of Requirements described latter.
Thus if the customer enters the code “ABC1-123” the discount will be applied as set for Coupon Code “ABC1”
NEW COUPON REQUIREMENTS FOR VALIDATING THE SUFFIX
Here are some suggestions of new coupon Requirements that can be used to validate the Suffix value:
• “The Suffix must be equal to the Customer_Id of the customer”. This is to have personalized codes that con only be used by the corresponding customer.
• “The Suffix must be equal to the affiliate assigned to the customer. This permits to have codes distributed by affiliates that can only be used by their associated customers.
• The following Restrictions are meant to make it more difficult to hack or falsification of codes:
o “The Suffix must fall within one of the following ranges”. Examples of range(s): MM01-M99; 001-800 or 1Z001-1Z999
o “The Suffix must contain the following text”. Examples of text: “ABC”, “NN”
• “The Suffix must have been assigned to this discount”. This is to assure that the Suffix was previously added to the table of associated Suffixes (discussed later) to the Discount Code. This is a strong check to impede hack or falsification of codes.
NEW DISCOUNT LIMITATION
In addition to the Discount Limitations of “Unlimited”, “N times only” and “N times per customer” include “N times per Suffix”.
ASSOCIATED SUFFIXES TABLE
A new table can be added to make sure that only the Suffixes within it can be used with a Discount Code. It can be updated by:
• Adding/deleting Suffixes individually
• Importing them from Excel
• Or some procedures to generate them automatically:
o Generate N Suffixes randomly of length X and with a prefix of “XXX”
o Generate N Suffixes sequentially, starting with “NNN”, of length X and with a prefix of “XXX”
SUGGESTIONS FOR USAGE HISTORY
• Include the Suffix used in each order
• Add the export to Excel all orders of which used the discount code.
NEW TOKEN FOR MESSAGE TEMPLATES
Include %Customer.Id% in the available tokes so personalized coupons can be sent with certain messages (examples: Customer.WelcomeMessage, OrderPaid.CustomerNotification) like “Here is your personal discount coupon ABC1-%Customer.Id% that will give you a 25% discount in your next purchase”
MVP
Silver Solution Partner
- 5236
- 49485
- 10/4/2010
- Mexico
C.A. wrote:
At the moment is on the roadmap for v4.00
Hi, would like to learn the status of this suggestion.
We have 2 different campaigns where we have to generate 5K and 10K unique promo codes on demand, i.e. once those are used up, we have generate another 5K and 10K unique promo codes.
Please advise.
We have 2 different campaigns where we have to generate 5K and 10K unique promo codes on demand, i.e. once those are used up, we have generate another 5K and 10K unique promo codes.
Please advise.
At the moment is on the roadmap for v4.00
MVP
Silver Solution Partner
- 5236
- 49485
- 10/4/2010
- Mexico
C.A. wrote:
Just generate individually or with SQL as many discounts as you want. What do you exactly want to achieve?
https://www.nopcommerce.com/boards/t/46712/nopcommerce-400-roadmap-and-estimated-release-date-lets-discuss.aspx
Many thanks.
In the meantime, is there a workaround? When will 4.0 be rolled out?
In the meantime, is there a workaround? When will 4.0 be rolled out?
Just generate individually or with SQL as many discounts as you want. What do you exactly want to achieve?
https://www.nopcommerce.com/boards/t/46712/nopcommerce-400-roadmap-and-estimated-release-date-lets-discuss.aspx