Free Module: Loyalty Points [genzo_krona]

[wakabayashi]

@AndyC and @datakick Is this an en error from conseqs or something of my module krona?

Btw: I haven't forgot about the expiration. It's still on my todo list. I just have too much other works, to do right now...

[dynambee]

On 6/7/2019 at 6:37 PM, wakabayashi said:

That was also my intention. This makes much more sense to me and is also clear to the customer. I mean a message like: If you don't place an order in your next 7 days, you will lose 10 of your 95 coins is just silly, isn't it?

Perhaps the way things expire could be user selectable?

In my case I would like loyalty points to expire if not used after X days (180 days, 365 days, etc). I don't want user orders to reset this counter because what I want to avoid is accruing a large liability of unused points. I guess this would mean changing the way points are stored in the db to match what @datakick described in this post.

Storing points on a per-order basis would also make it easier to know how many points to remove if a customer returns a purchased item.

While it would mean rewriting part of the module it seems like it would be a more flexible overall solution.

[wakabayashi]

Tbh: that would be quite a huge rewrite/extension. And I really don't believe it's user friendly. 

If somebody is interested to code this solution, I am open for merging something. But I won't code this "feature" myself.

When I am looking again deeper at the module I will think, if I can implement a solution for customer returns.

[dynambee]

11 minutes ago, wakabayashi said:

Tbh: that would be quite a huge rewrite/extension. And I really don't believe it's user friendly. 

I really appreciate that you made this module and released it to the community and I do not wish to come across as ungrateful in any way. Thank you for your time and hard work.

I just think that allowing unlimited points to accrue with no expiration could end up being a problem for a merchant. Not immediately of course but 2, 3, 5 years down the road. Enabling point expiration allows merchants to mitigate this risk while also encouraging customers to return and use their points before they expire.

As an aside, AFAIK accrued loyalty points should be recorded in the accounting books as an unrealized loss. I'm not sure if the module shows the total outstanding point value or not but having a way to do this would be helpful.

Edited July 15, 2019 by dynambee
2,3,5 years note

[wakabayashi]

12 minutes ago, dynambee said:

I just think that allowing unlimited points to accrue with no expiration could end up being a problem for a merchant. Enabling point expiration allows merchants to mitigate their risk while also encouraging customers to return and use their points before they expire.

Yeah I got this. That's why I want to implement the expiration feature. But I really don't get the point having part "expiration". Either it makes no difference at all (when customer doesn't order anymore and lose all it's coins). Or the user loses a part of his coins (in your way) and none coins (in my way). But I as a customer would be totally angry if your case comes in. If I place a new order at your store and still lose some of my coins I would think: Ar they kidding me? I am still buying stuff there, but still delete my coins :S

In addition: how likely is this case? As far as I understand a loyalty points system almost always works like this: You order something and collect a few points. You use them on your next order and the thing is done. Doesn't 99% of the orders work like this?

12 minutes ago, dynambee said:

As an aside, AFAIK accrued loyalty points should be recorded in the accounting books as an unrealized loss. I'm not sure if the module shows the total outstanding point value or not but having a way to do this would be helpful.

Probably the module doesn't show it. But I get your point. There is nothing wrong in adding this number somewhere 😉

[dynambee]

1 hour ago, wakabayashi said:

Yeah I got this. That's why I want to implement the expiration feature. But I really don't get the point having part "expiration". Either it makes no difference at all (when customer doesn't order anymore and lose all it's coins). Or the user loses a part of his coins (in your way) and none coins (in my way). But I as a customer would be totally angry if your case comes in. If I place a new order at your store and still lose some of my coins I would think: Ar they kidding me? I am still buying stuff there, but still delete my coins :S

My idea was that coins would slowly expire over time if they aren't used. This seems kinder than losing all coins at once if a customer doesn't make any purchases for X days.

If a customer does use coins then the coins they use would be removed from their oldest coins first, going forward. So if they had 200 coins from 3 months ago and 300 coins from last week, the coins they used would be removed from the older 200 coin balance first. If they use more than 200 coins then the extra coins would be removed from the newer 300 coin balance.

 

1 hour ago, wakabayashi said:

 In addition: how likely is this case? As far as I understand a loyalty points system almost always works like this: You order something and collect a few points. You use them on your next order and the thing is done. Doesn't 99% of the orders work like this?

I guess it depends on how the module handles coins. In my experience some customers like to save up coins until they have a lot of them and then use the coins to make a "free" purchase. Some customers might save coins for years and then use them all at once to buy something expensive. In my example situation from above coins would slowly expire over time so that customers couldn't do this saving process. Basically I sell expensive items and have some regular customers. I like the idea of loyalty points but I don't really want a situation where a customer has $1000 worth of coins and uses them all at once. I don't want to have to carry that unrealized loss for years on the accounting books and I don't want to have to suddenly cover a large quantity of coins all at once.

Also, a quick question about how the coin amounts are calculated:

Let's say I give 5% coins for purchases. Customer has 1000 coins ($10) saved in their account. Customer makes a $50 purchase and uses all 1000 coins. This means the customer pays $40 by credit card and $10 by coins.

How many coins do they get for this order? 5% of $50, 250 coins or 5% of $40, 200 coins?

[wakabayashi]

It's been a long time, since I last worked on krona. I started today a bit with v.1.2.0. I added:

• Expiration of loyalty points (but not the history way)
• Stats for total value of outstanding loyalty points
• Functioniality to hide players from leaderboard

Hopefully I can test things with @SLiCK_303 soon.

@datakick Is it possible to integrate an email warning conseqs module? Like your module checks, the loyalty_expire column in my module?

What else are your expierences? Where is the module "weak"?

[wakabayashi]

On 7/15/2019 at 5:41 PM, dynambee said:

Let's say I give 5% coins for purchases. Customer has 1000 coins ($10) saved in their account. Customer makes a $50 purchase and uses all 1000 coins. This means the customer pays $40 by credit card and $10 by coins.

How many coins do they get for this order? 5% of $50, 250 coins or 5% of $40, 200 coins?

You can set this up as you want...

[wakabayashi]

I am doing more rewrites than I was planning. Probably the new version will be released as V.2.0.0.

So if there are any suggestions, it's best to do it now. 

[dynambee]

I guess if you can give a rough outline of what you are changing then maybe people will have some ideas that can be included in those changes?

[wakabayashi]

In general I rewrite quite a lot of functions, since I became a much better coder than I was back then. 

This is changed:

• Expiration of loyalty points (but not the history way)
• Stats for total value of outstanding loyalty points
• Functionality to hide players from leaderboard
• Functionality to show possible actions in FO

I am thinking of:

• adding email support
• referral/affiliate functionality
• better handling of history (for example for product returns, cancelled orders)

[dynambee]

Those are all fantastic additions that will make the module more flexible for shop owners.

I really like the referral / affiliate functionality idea. For referrals, will there be a way to award points to the referrer only after their newly referred customer spends $X amount in the store?

[vincentdenkspel]

I also like the referral/affiliate option. If you are going to implement this i hope you can make it such that people can be paid in money or can get an voucher.
For example: if they want to get paid in money they earn 5% for each order placed by the referral. They will get 7,5 % if they in the choose a voucher.
These percentages can be set by the merchant in the backend

 

[wakabayashi]

@vincentdenkspel that's an interesting proposal. 

TBH I don't have too much experience with Affiliate and Referral. What is important here? Actually what is even the difference? Which modules are you using right now for this functionality?

[vincentdenkspel]

@wakabayashi https://www.saasquatch.com/blog/rs-referral-marketing-vs-affiliate-marketing/

[dynambee]

6 minutes ago, wakabayashi said:

@vincentdenkspel that's an interesting proposal. 

TBH I don't have too much experience with Affiliate and Referral. What is important here? Actually what is even the difference? Which modules are you using right now for this functionality?

I'm not sure that the two words necessarily have perfectly separate uses when it comes to web use.

However in my understanding generally a referral would be when a new customer makes an account on the website using a link with a referrer code in it. Usually in this case the referrer gets a percentage of the sales of the person they referred (maybe for a fixed period of time) or they get a one time payment. Especially in the case of a one time payment the new customer usually needs to spend a certain amount in the store before that payment is made. Otherwise it is quite ripe for abuse where people make new accounts with fake names & emails but never purchase anything.

Affiliate links are usually links to specific products. For example product reviews often contain affiliate links to that product on Amazon or other sites. If a customer comes to the site via an affiliate link and then buys something, the person who sent them to the site gets a percentage of that sale. The rules for affiliate links are often fairly complicated. For example, the person coming to the site must not have visited the site within the last X number of days (checked with cookies), and they have to purchase something within X days of the affiliate link visit (again controlled by cookie). Sometimes the payout is only for the product they were specifically referred to, other times it can be for anything they buy within that X day period.

[wakabayashi]

Ok I believe that for most people referral programm is more interesting, right? 

Customer gets a code and his friend is typing this code when he orders. Then one or both of them get a reward. Is it that, what it should be like?

[wakabayashi]

@dynambee and @30knees you two asked for expiration of loyalty points with a history right? I am rewriting the module right now and maybe this is possible to integrate. Still I don't understand the logic for sure.

An example:

1. Customer places order_1 and earns 20 loyalty points. (exipration date end of october)
2. Customer places order_2 and earns 30 loyalty points. (expiration date mid of november)

Customer places order_3 and uses 15 loyalty points - what happens now? Will any expiration date change? Or is this just always fix?

If it's fix, it means, that this customer has now 3 expiration dates left (5 from order_1, 30 from order_2, and some from order_3). I would call this the "fixed way".

On the other hand I plan to add the "refresh way". (which I like more). In this way when customer places an order all his loyalty points are updated to a new expire date. 

[vincentdenkspel]

@wakabayashi both ways has advantages and disadvantages: Wit the "fixed way" customers can't hoard loyalty points. As i understand this works according to the FIFO principle (the oldest point will be used first)
From a merchant perspective i think this is the best way. From a customers perspective this may the a less friendly version.

With the "refresh way" it is possible to to hoard the loyalty points. 

Hoever, personally i think the "fixed way" (FIFO) is the best way. If we the merchants can set the expiration time it think every merchant can decide for for him/herself what he/she thinks a reasonable expiration time is.

[wakabayashi]

@vincentdenkspel yes you are right with the FIFO and also with the merchant friendly/customer friendly. 

As most merchants seem to prefer merchant friendly than customer friendly (😜), I want to add both possibilities. Ofc the merchant can set, after how many days the points should expire...

[dynambee]

@vincentdenkspel summed it up perfectly, and with a whole lot fewer words than I would likely have ended up using.

@wakabayashi, I'm excited about the new version coming out and am very grateful for all your hard work on this!

[dynambee]

On 9/29/2019 at 1:20 AM, wakabayashi said:

Customer gets a code and his friend is typing this code when he orders. Then one or both of them get a reward. Is it that, what it should be like?

Yes. I'd like to be able to set a minimum order value though. Don't want people making $2 orders and then giving them and their friend each a $5 coupon. So ideally friend gives out referral code, and then if the person spends (for example) $50 or more then they get a $5 coupon and their friend gets a $5 coupon.

It could be integrated with the points system so the person making the order gets $5 worth of points that they can use on their current order and the friend gets $5 worth of points added to their point balance. That way a separate system to manage the coupons isn't necessary.

Edited October 2, 2019 by dynambee

[vincentdenkspel]

2 hours ago, dynambee said:

Yes. I'd like to be able to set a minimum order value though.

You can overcome this buy using % of order instead of fixed value.

Furthermore i would like to have the possibility to set different values (€ / %) for referrer and friend.

Also i would like to see that the coupon is activated after x number of days. 
Here in the Netherlands, people have the right to return the products until 14 days after delivery. The coupon should automatically be activated only after these 14 days.
Otherwise people could buy for a large amount, get an coupon , use the coupon and than return most/all of the products
 

[dynambee]

21 minutes ago, vincentdenkspel said:

You can overcome this buy using % of order instead of fixed value.

The trouble with this is that I sell items that range in value from a few cents (small parts) to $5000 and sometimes more. I’m happy to give 10% off a $50 order but not 10% off a $5000 order.

23 minutes ago, vincentdenkspel said:

Also i would like to see that the coupon is activated after x number of days. 

Certainly for the coupon to the friend having a delay of a couple of weeks or a month would be a good idea.

[wakabayashi]

Thanks for your inputs @dynambee @vincentdenkspel

For now I am still at the rewriting part. The player history is trickier than I thought. Nobody of you was using this module until now?