Re: |redirect| tag versus |subscriber| fields tag replacement

 
From: "Alex Judd" <alex@PROTECTED>
In-Reply-To: Re: |redirect| tag versus |subscriber| fields tag replacement
Date: October 15th 2009

|> So that if you have URLs containing information such as the segment |> of the database you are emailing, the redirect seems to include the |> in the link rather than substituting the values first, then |> creating the redirect | |I understand exactly what you're saying and I think you're right If |you do write a redirect with a tag, the tag isn't really ever going to |be replaced with the value Here's why:

Thanks Justin - that does make total sense and yes can understand why it would be a performance hit however agree that the whole model of the click tracker could be refined to work better for what we're using it for

A lot of our clients are asking for sales conversion from their emails - I know DaDa has always been more digest focused but you never know what people will use your tools for when you put them out in the wild :-)

So it would be great to be able to call back to the clicktracker once a 'Goal' (think Google 'Funnels') had been achieved to update the value of a campaign with a sale

Also, it would be great to encrypt/anonymise the information that DaDa dynamically places into an email, so say for example you wanted to track the country again then we could use |encrypt:|subscriber_country|| and apply a MD5 hash or similar to the value so that it doesn't flag any privacy alerts in email clients

However if we had a unique click url per link per email, then we could swing back and look up the subscriber country rather than having to use the |country| tag to specify it!

Lots of good thoughts :-)

Alex

rss/atom
‹ Re: |redirect| tag versus |subscriber| fields tag replacement
Index
(no subject) ›
  • This mailing list is a public mailing list - anyone may join or leave, at any time.
  • This mailing list is a group discussion list (unmoderated)

  • Start a new thread, email: dadadev@dadamailproject.com

This is the developer discussion mailing list for Dada Mail.

If you are just looking for support Dada Mail, consult the message boards at:

https://forum.dadamailproject.com

Documentation for Dada Mail:

https://dadamailproject.com/d

Specifically, see the Error FAQ:

https://dadamailproject.com/d/FAQ-errors.pod.html

To post to this list, send a message to:

mailto:dadadev@dadamailproject.com

All subscribers of this list may post to the list itself.

Topics that are welcome:

  • Constructive critiques on the program (I like, "x", but, "y" needs some work - here's an idea on how to make this better...)
  • Bug/Error reports
  • Bug fixes
  • Request For Comments on any changes to the program
  • Help customizing Dada Mail for your own needs
  • Patches
  • Language Translations
  • Support Documentation/Doc editing, FAQ's, etc.
  • Discussion of any changes that you would like to be committed to the next version of Dada Mail -

Dada Mail is on Github:

https://github.com/justingit/dada-mail/

If you would like to fork, branch, send over PRs, open up issues, etc.

Privacy Policy:

This Privacy Policy is for this mailing list, and this mailing list only.

Email addresses collection through this mailing list are used explicitly to work within this email discussion list.

We only collect email addresses through our Closed-Loop Opt-In system.

We don't use your email address for any other purpose.

We won't be sharing your email address with any other entity.

Unsubscription can be done at any time. Please contact us at: justin@dadamailproject.com for any help regarding your subscription, including removal from the mailing list.

All mailing list messages sent from us will include a subscription removal link, which will allow you to remove yourself from this mailing list automatically, and permanently.

All consent to use your email address for any other purpose stated at the time of the mailing list subscription will also be revoked upon mailing list removal.