View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009488||phpList 3 application||General||public||17-03-07 05:04||21-06-18 14:00|
|Summary||0009488: linktracking explained|
|Description||Hello - yesh! I am trying to understand how the new link tracking works - is there any documentation around the process now? I see about 3 new tables for link tracking and some new code. Would be great to have even some high level documentation on this to help you test in.|
||For example is the new code designed to reduce the table size for link tracking - if correct then how does it do that? From a brief look so far the code checks to see if a url is already in the link track table and reuses that link for each email.. Is that correct?|
||each email within a message I mean. So for each subscriber to be sent the message the code reuses any links that have already been added to the linktracking database - avoiding duplicating the url for each subscriber.|
This is what is mentioned in the development wiki:
- click tracking has been completely overhauled.
the current system creates very large database tables when you have a lot of users, messages and/or links, so I've rewritten it to store it across multiple tables that each will be much smaller. I've also added a method to convert the old data to the new one. (page=convertstats)
This is what is mentioned in the release notes:
# statistics for click tracking are cached in memory and flushed to the DB every now and then to avoid large amounts of queries while sending messages, and therefore to speed it up a bit (more speeding up is on the way).
# link tracking will add a variable "entrypoint" to the session, so that this can be picked up by the CMS to find out more about what happened afterwards, eg, to extend into email to sales tracking. This probably still needs some work.
# added a "clicktrack linkmap", which allows making the tracked links in the emails look a little more professional, eg if the current tracked link is /lists/lt.php?id=ABCD you can have it be turned into /lt/ABCD
That does of course require an Apache RewriteRule to work.
Okay, that provides some information. It still seems that a table record will be created for each subscriber and each link within the message. For example:
Subscriber A :: Link A
Subscriber B :: Link A
Subscriber C :: Link A
This seems to me to be a waste of table space if Link A contains no personalisation.
What I was thinking is trying to reduce the amount of table records by only recording a url (Link A) within a message once IF the url contains no personalisation (uid etc...).
For example a message might have a url like this (http://www.phplist.com). Now what is the point of recording for each subscriber a link track record for that url? Why can't we record the url once and then in the link track reference that link track url record id for each message.
Then when a subscriber clicks on the link track within the message phplist records the subscriber and then gets the target URL.
Amazing! I have just reviewed the new code and I have to say its impressive! Here are my findings so far
phplist_linktrack_forward - contains all urls within message - including urls with personalisation though the uid parameter is removed so the url only needs to be added to the link track table once.
phplist_linktrack_ml - contains total stats on clicks - does not cover uniques
phplist_linktrack_uml_click - contains users click stats
Fundamental rule - for a link to be personalised it must contain a "uid" parameter. The uid parameter is not inserted with the url into the link track table as this allows the url to be reused not only in the same message but all subsequent messages - brilliant!
When a user clicks on a link which needs to be personalised - example unsubscribe and change preferences the lists/lt.php will check the phplist_linktrack_forward table and if the url is tagged as personalised the code within the lt.php file will get the users unique hash and append that to the url !
The new code is awesome and I am very impressed with what the PHPList team has done. I will continue testing and report my findings here.
|Closing issue because it is too old. If you feel it is still relevant please add again and give the new context. Thanks!|
not sure why it was re-opened, but I guess it could do with some explanation in the documentation