Selectively SKIPPING followups based on Products?

[DW]

Thanks Dan... I just don't know what to say, really.  I did make a mistake in that I offered the service for a set rate before realizing the time and effort involved.  I also was not able to predict some of the time-consuming and emotionally-draining things happening in my life right now.  I provide custom scripts on occasion as a one-off service - for simpler jobs and integration, usually.  As per a discussion some time ago I believe we all decided I should do less paid-for-features.  Now, for the benefit of all I try to spend my time focused on support, bugs, improvement and planned/unfinished development.  I most certainly do not have time to argue about business practices or implementation...  This is why I've been pretty much avoiding response - I don't have the time or energy to argue  I have thought about revisiting this request but would really rather avoid the drama at this point... :?  I prefer to work with those who can understand and respect my position as a one-man-operation and are patient and supportive of my efforts to help them as best I can.  I try to please everyone all the time but it's inevitable it will fail on occasion.  I still greatly appreciate any and all suggestions, especially from thoughtful individuals who push my program to the limits.  Even though he can be hard on me I still appreciate Brett as a client and hope to implement at least some of his requests in the immediate future, for the benefit of all.

Regards

[mr.trevor]

Well, there's a turn up for the books...  

I was slated previously by Brett for suggesting that once simple data was put in the database it could be pulled out to provide more comprehensive reports.
It was said at that time that I did not appreciate how much work it took and that:
"That's over a one year job to guarantee a fully debugged and working version of Click-through rates, etc, etc, etc... do you have a year to wait around for that, with all the other features asked for, it's more likely a two year job."

As there seems to be a 'demand' for adding 'simple' features and a number of PHP programmers using the forum that would benefit from these additions, I wonder if there would be any system that would allow them to donate any solutions they code to DW for consideration and inclusion in the distributed 'official' code.

Maybe this could speed up non-essential but desirable additions.

Just a thought...  :wink:

[AlanT]

This has been a very interesting thread.  

The concept of promoting multiple products is one that has been around for a while, and one that I have been considering for some time.

Please forgive me if I'm way off base here, but from my newbie perspective, it seems to be a fairly easy problem to solve, and one that doesn't require much (if any) custom programming.

Why not set up separate prospect lists for each product, and when someone is initially added to the system, have them subscribed to all lists at once.  Then, as they purchase each product, they are removed from that one list, thus never again receiving promotions for that product.

For instance, if I have 20 products to promote, a prospect gets signed up to 20 different prospect lists.

Each list has a different delay for the initial followup, so that the prospect only gets 1 message at a time.  For this example, let's say that list1 has the first followup set for a 0 delay, list2 has a delay of 1, and so on.

Thus, our prospect gets a new message once a day for 20 days, each promoting a different product.

Then each succeeding followup is set for a delay of 20 days.

If each list has 10 followup, the prospect gets a daily message for 200 days.

If we also have a separate list for each product that a customer gets added to after they purchase that product, then we can use the signup rules to remove them from the prospect list when they are added to the customer list.  For the above example, we now have 40 lists.  The customer lists don't have to have any followups, but can be used simply to manage the prospect lists.

And using the signup code available elsewhere on this forum, we can easily have this process automated.

What am I missing?

[BGSWebDesign]

Hi Allen,

What am I missing?

Here's exactly what you are missing, and why you, or others can't see this is beyond me.

If I have 10 products (prod1, prod2, ... etc, prod10).  

Your system works - EXCEPT for one major flaw, the flaw is this.  I want my prospects to be MOVED UP in the list to the next product that is poromoted AFTER they have purchased any product.   This can ONLY be handled with ONE LIST, and with a field in the list that tracks WHICH PRODUCT the customer has purchased (somewhere in a custom field for the customer).

(*Keep in mind, my list CYCLES, so the user could be anywhere in the list, or they could be cycled back to prod1, after having seen the prod10 promotion.)

Here's a very detailed example.  Customer starts the list, gets promoted to for prod1, then prod2, (CUSTOMER PURCHASES prod3), let's say for the purpose of example, this customer has already cycled through the list and not purchased anything the first time round - but they saved the emails with the promotions... AFTER the customer received their prod2 promotion - they purchase prod3, and get even more excited and go through their old promotion emails even further and also purchase prod4 and prod6 (and YES this really does happen).   NOW - here's exactly what needs to happen, this customer has purchased:
prod3, prod4, prod6 (but they are currently on seq prod2 - ready to be moved up to prod3).

Using your example of 1 product/day (which is not likely in my scenario anyway, but I'll use it), instead of this prospect receiving prod3 promotion tomorrrow, they now need to receive prod5 promotion, after prod5 promotion they need to receive prod7 promotion.

As you can see - there is NO WAY you can handle this simply with 10 different lists, here's why, let's say you had
prod1
prod2
prod3
prod4
prod5
prod6
prod7
prod8
prod9
prod10

If you remove the user from lists prod3, prod4, prod6, that user (IN YOUR EXAMPLE) would NOT receive their next promotion until prod5 (which is 3 days away), and not anywhere near the correct sequence (this is probably fine for 1 day delays - but expand your thinking, my delays are 3-4 weeks, using this example they would miss 9-12 weeks of promotions waiting for their prod5 promotion, as they would be skipping prod3 and prod4.  

So (using your way of doing it Allan), EVEN IF you had a script to look say, they bought a product, you would need to know they bought 2 products, or 3 products AND THEN you would need to move that user ahead the number of products they bought (from the current day -> to the next prod promotion day FOR the total number of products they have bought today), secondly, you'd have to save this information somewhere, AND your script would have to remember that they bought prod3, and prod4 ON THE SAME DAY (and NOT on different days), so that you could advance your Seq# and Del# the correct number of days....

If you think this IS a convenient way to do this, I'd sure like to see your script - and while your at, ALL OF THE TIME - think about how much easier it would be managing TWO LISTs - and not 20 LISTs as you propose - and by the way, I have nearly 30 products, so as I add more products your methods require double the number of lists, over and over again, imagine 100 products, you'd need 200 lists!  

Do you REALLY, REALLY think this is efficient way to handle it?  

Let me explain (for about the TWENTY-FIFTH time) WHY (and how) you could do this very easily with one list.   You simply add ONE FIELD, that's it ONE FIELD to the Followup Database, that field is called Campaign (which in our example above would contain prod1, prod2, etc - but always ONLY one CampaignID for each followup - so for example the first Followup in the list would have "prod1" in it's CampaignID field, the second would have "prod2" in it's field, etc..), and could be used to tie any Followup sent out - to a specific campaign, then what you do - is you use ONE SINGLE FIELD in your Custom Customer Fields to store your campaigns that user has purchased (for example see above - it would contain "prod3,prod4,prod6," exactly like that).

Now, what you do when the user purchases, you add the CampaignID to the Custom Customer field every time the user purchases - so that you can get a record of the past purchases - NOW that you have that simple thing setup (1 field added to the Followup table, and 1 custom customer field used for purchases), when you run your DAILYMAIL function, you add an 'extra' script (or whatever it's called) that also runs with DAILYMAIL - LMP is currently already setup to do this...  When the extra script runs - it looks at the current sequence the user is on (prod2 would be correct in our example), and it looks at the NEXT COMING FOLLOWUP (prod3 in our exampe) at the newly added campainID field for the correct campaign (if it finds a match with this campaign, "prod3" in our example,  IN the Custom Customer field) where you store the purchased campaigns - indicating that customer has already purchased that product, instead of going to the next product in the sequence (prod3 in our example) this user now needs to be moved up to the next Seq# after prod3, (continue doing this until there is NO MATCH in the custom customer field). When you have cycled through the upcoming Followups and NOT FOUND a campaignID that matches a campaign in the custom customer field, you know the user is setup to receive the next upcoming product that they HAVE NOT PURCHASED, and continue correctly on in the list, the script may need to run through 2, 3, 4 or 10 next followups looking for one that the user HAS NOT PURCHASED and set them up for that Seq# in the list (it also needs to loop if the Followups are setup to loop), also the script needs to do one other thing - WHEN THE Customer has purchased every single product in the list of all products in the Followup Sequence (as it currently stands), the User can be removed from the list entirely, or be added to a different list of 'SUPER Purchasers' or something similar...

I hope I'm VERY Clear this time, don't make me repeat this a million times, as it will be very inefficient, just as your method of using 20 different lists to promote 10 different products is inefficient...

IS IT CLEAR NOW???

[DW]

I'm moving this to development because it seems to contain a lot of good information about this suggestion.  When a number of other promised features are done for the next update I will be able to take another look at this.

Eventually I would like to modularize followups and allow multiple followup sets to be applied to a single list - perhaps this feature could help.  When the user purchases one product they could be removed from that followup set and move on to the next, if any.  I don't expect to modularize followups very soon, however, and I will likely look into this again before then.

Regards

[AlanT]

If it's so easy, why don't you do it yourself?  Or hire a coder for $35/hr and have it done for $10?

Okay, so I hear that you don't want to promote the products concurrantly, but sequentially.

I certainly don't claim to be an expert here, nor do I claim to have the 'perfect' answer.  I'm simply offering a possible solution using what LM currently has to offer.  

There's usually more than one way to solve a problem, and I've gotten the impression that maybe you're hung up on only one possibility.  I've certainly been there myself, as Dean witnessed when I first converted to LM.  I now realize that there was another way to do what I thought HAD to be done only one way.

It feels as if you have been berating everyone here because they can't see it your way.  Have you tried seeing it from another perspective yourself?

It just seems to me that the answer lies in using multiple lists somehow and the LM feature of switching a subscriber from one list to another under certain conditions.  That would certainly be less resource intensive than trying to add more comparisons to every mailing that goes out.  After all, very few of us need such a feature.

Since LM gives us the ability to move a subscriber from one list to another in sequence, this would take care of the "one product at a time" requirement, and working with the delays will produce any required timing.  And with the "unsubscribe from list X when user subscribes to this list" feature, that would automatically jump a user ahead in the sequence when they make a purchase, using code that is available here on the forum.

Just offering suggestions for what I see as possibilities.  Take from it what you will and leave what doesn't meet your demands.

[BGSWebDesign]

Hi Alan,

Have you tried seeing it from another perspective yourself?

Yes, and as I appreciate that you offered that, I'm sorry if it came across a little 'abrasive'.  But, as I indicated, I have 30+ products, I don't want another 60 lists to manage those products, and secondly, as indicated above, writing the script to handle that using your method would be next to impossible, and much more work than handling it the way I've indicated.

I have considered writing it myself, and probably will, BUT, consider this, when you write it yourself, you've pretty much locked yourself into your own version, since when the next version comes out you'd have to 'rewrite'everything again to the standards of that version, so hence, the hesitancy to write it myself, I certainly would be comfortable doing it, but the time involved every time a new version came out would not be fun, now would it?

Part of the other reason I don't see WHY this is such a big deal is because the change I ask for would not take that much time to code, the testing would take some time, but when I ask DW and pay DW to do things (and yes, I am going to pay him extra to make these changes, they are not free support), then I generally do all of the testing myself, saving him that time.  Secondly, I wouldn't be recommending it if I didn't feel it could be used by others, and thirdly DW, I don't believe Modularizing the Followups will help **unless you're going to give me a custom field for the followup, in which case it very much could help, as I could use that field for my 'CampaignID' as indicated above, and I very much could then write my own 'extra' script to handle the updates on the Seq/Delays as indicated....

It just seems to me that the answer lies in using multiple lists somehow and the LM feature of switching a subscriber from one list to another under certain conditions. That would certainly be less resource intensive

No, it doesn't lie in multiple lists, as it that would create more problems to manage, and make writing the script to handle the Seq/Del updates more difficult, and it is not less resource intensive, unless you consider managing about 60-100 lists less resource intensive than managing 1?  See below...  Also, I'm not 'new' to this, and I'm not a 'newbie', I have a degree in computer science with a concentration in database management systems - many times I see these type of 'questions'/issues come up with people who do not have experience in this area and believe that they know a 'better way' to handle/manipulate data.  I've studied databases for many years and ran my own company doing custom database development - so I know how to formulate needs requirements and make them into working products - this requires knowledge of how to optimize and relate databases reduce them to 3NF (third normal form) and understand how they work together to solve a problem - in other words...  I'm talking from experience.

Regarding your question about seeing it another way, sure, many times there are 'other', 'easier' ways, but most of the time those come at a price, as indicated above the price this time is handling huge numbers of lists (60 or more) to do what I want, which is not pleasant at all  :twisted:  so, you see, the 'other way' is usually some inefficient or 'hacked' way of handling something which could be handled much more elegantly to the benefit of all involved....

Hope that all makes sense and thanks for the input, I do appreciate it...

DW - please do consider the 'modularizing' of the followups if this will include the ability of anyone to add a 'custom field' to the Followup, that way I can tie the Followup to a specific Campaign.

Oops, I just had a closer look at what you said:

I would like to modularize followups and allow multiple followup sets to be applied to a single list

I don't believe that is going to help - what would help is one simple change, please consider it (and then I'll write everything else myself) - what I need is ONE CUSTOM FIELD in the Followup that I can assign a CampainID to, that's it... make it at least 20 chars long...  if you do that, I'll be able to achieve everything else I want by myself and everyone else can let this rest... until someday they find that they do need it  :?

[AlanT]

Hi Brett,

You've got me intrigued now.  The example of daily emails was just an example because I didn't know your system.

When I proposed a collection of lists, my thoughts were that the lists would be set up once and then forgotten about.  I'm not sure what type of 'management' they require on an ongoing basis.  My lists (12 of them) are for single products only, and I never spend any time with them after setting them up.  The prospect of having 1000 lists doesn't intimidate me, especially since I can create User Selection groups where I can mail to everyone at once.

I think I understand now that in your system, you promote one product at a time for several weeks before moving on to the next product in the sequence, and then restarting the whole process as in a loop.  I also understand now that you simply want to remove the product promotions from the sequence that the customer has previously purchased, while maintaining a steady flow of communication.

{Forgive my ignorance here, your posts were so long I only skimmed them instead of actually READING them.  I've gone back and actually READ them now.}

To do that, the system WOULD need to keep track of which products were purchased and skip the followup sequences that relate to those products.  As I see it, this could still be done with multiple lists or a single list as you mentioned.  

The only thing I see in your proposal is that multiple data items would be stored in a single field, which I imagine takes more processing than using a separate table.  (The resources I mentioned were the processing cycles of the server, not the administration time involved, which I also try to minimize as much as possible.)

To my mind, using multiple lists still makes more sense, as the list itself can be used as a CampaignID, thus eliminating a core database change.  In fact, it's possible to do this without ANY LM database changes.

In fact, the only thing that would be required would be an extra check when a customer makes a purchase, or when they have completed a product specific followup sequence (which is easier to track with multiple lists).

I realize that all of your prospects are in a single list and separating them out into separate lists would require massaging the database to Update the user table in order to move them.  I figure that a small script could be written to make the process go smoother, so you can update cseq and cdel numbers as well.  Maybe a series of Update queries like:

Update lm_users where ((cseq > x) and (cseq < y)) set list = NEWLIST, cseq = cseq - z

(This may be syntactically incorrect, but you get the idea.)

Okay, so here's what I see at this point, and I hope it provides a helpful clue.

What if....

30 products, each with a followup sequence that covers 3-4 weeks.

30 lists, each for a different product.  Each list is set so that when the subscriber has completed the list, they are automatically moved to the next list in the sequence, as set in the List Settings screen (Followup Options #2 - I figure it's there for a reason).    

The last list in the sequence points back to the first list to 'round robin' the user.  When a new product is added to the set, its list points back to the first list and what was the last list is edited to point to the new last list.  60 seconds of administration beyond the creation of the list and followup sequence.  Adding a product to the middle of the sequence takes almost the same amount of time.

What we need is a table that relates products purchased to a user ID, and after each sale, a new row is added that stores the user ID and something that identifies the product, which could be the list id associated with that product.  It could also be the sales data in your sales system (shopping cart or other).  A LM custom field can identify the user in the other software, thus eliminating any LM database changes.

Next, we need LM to perform a maintenance script when moving the user from one list to the next, to check if the user has already purchased that product, and if so, to move them to the following list, where the checks are performed again.  If all products have been purchased, then the user is moved to a 'waiting' list, where you can promote future products.

{Doing the checks when a user reaches the end of a list is much less demanding of server resources than doing the checks for every followup that goes out.  The custom script that checks for products purchased can check data stored in either the LM database OR the sales system database, using a custom user field to identify the user.}

I suppose that LM can be easily edited to process another Xtra script at this point where all the custom processing occurs.  This would eliminate much of the "upgrade hassle" that you're worried about.  And maybe Dean will see this as valuable enough to add in to the system as a normal feature.

Outside of LM, the sales system would need to relate the sales data to a LM user id.  This could be in the creation of a sales entry in a new LM table, or storing the LM user id in the sales system, or storing the customer ID (from the sale system) in the LM user table as a custom field.

We also need to trigger the moving of the customer to the end of the sequence, thus triggering the series of checks to get them to the right list.

Within LM, a new Xtra script to process the custom requirements, and possibly a new table to relate the user to products purchased.  (This would be even easier if LM stored the custom field data in a separate table, thus allowing for an unlimited number of options.)

In total, the extra code required would be the series of checks you've proposed, and some code after a sale that adds an entry to a database and moves the user to the end of their current list (which is known based on the product purchased.)

Administration time required outside of setting up the system is vitually nil.

[BGSWebDesign]

Hi Alan,

Yes, having read this I see your point (enlightenment)!  

Yes, a tiny lighbulb went off when I saw that you mentioned you can point users to be moved to another list when the sequence ends, I forgot about that being in LMP.

It does make sense, but as far as managing 30 lists instead of one, it's not as much fun for me, I know you say it's not time-consuming, but I'd much rather work with 1 list than try to track down users in 30 lists, but, I can live with it.

Regarding this:

would be the series of checks you've proposed, and some code after a sale that adds an entry to a database and moves the user to the end of their current list (which is known based on the product purchased.)

I would have to store in a database separate from LMP, I run Miva shopping cart which uses proprietary dbf (dBase) format so I can't get to the data in that cart very easily, unless you can think of something there, I would probably do this - pull the data from the DBF database file one time (when I initially load up a MySQL table) with the user email address, and product they have purchased, one row for each purchase.  Then from now on, any purchases that take place I call a simple script that runs via Email - since my LMP runs on an entirely different host from my shopping cart.  Basically I do something similar to that now - using a procmail script to handle signups: the shopping system sends an email when purchase is made, and the script inserts the user via a simple LMP insert script.  

This is the one thing I'm not clear on:

Next, we need LM to perform a maintenance script when moving the user from one list to the next, to check if the user has already purchased that product, and if so, to move them to the following list, where the checks are performed again. If all products have been purchased, then the user is moved to a 'waiting' list, where you can promote future products.

DW, is there any way to have a script when a user is moved from one list to another?  Would the "extra" script work here?

You've inspired me to make this work now, and I have users clamoring to stop getting promotions for something they've already purchased, so that will help to.

Thanks for taking the time to give me a different viewpoint.

[AlanT]

Glad that my ideas weren't totally worthless, and doubly glad that they have inspired you.

Take care.

[BGSWebDesign]

Alan,

There's one little thing I'm not sure of, DW may have to answer this...  see above, I added some text.  Regarding the 'little script' that runs when a user is moved from one list to the next...

Will signup-xtra.php work for this???  

There's not much I find on it, but this is in the file itself:

Code: [Select]

 NOTE: This script will run after every non-manual signup to every list.

Please tell me DW, will this script run when users are being moved from one list to the other using the List Settings option:

Code: [Select]

Move users who reach end of followup sequence to list

Please let me know, if it does not, a quick change in code somewhere, and perhaps it can be ran, OR, better yet, setup a different script, move-xtra.php to be ran every time a user is being moved from one list to another?

How about it DW?   Really, I think it's better suited to having a move-xtra.php script, can you please add that to the LMP code so that it calls move-xtra.php every time a user is being moved?

[AlanT]

I'm not exactly sure of the details, but it looks like you're on a constructive path.  I guess that doing a text search on the PHP files will reveal when the signup-xtra.php file is being called.

And I'm also guessing that when you find how that one is being called, you can add a similar bit to call a separate move-xtra.php file once you find where that is being done, if that is indeed a separate process.

[BGSWebDesign]

Hi Alan,

you can add a similar bit to call a separate move-xtra.php file once you find where that is being done, if that is indeed a separate process.

Thanks, I know that, what I'd like to hear is from DW that he will add a call to move-xtra.php in LMP, that way I don't have to go in and hand edit the file that I have to change every time a new version comes out.

[DW]

I have replied in another thread, here:

http://listmailpro.com/forum/index.php?topic=1731.0

Regards