When you create a link in Infusionsoft’s Email Builder, you are given the option to “Place the person’s details at the end of the URL (for techies)”. But should you use this feature? The short answer: no, you shouldn’t.
The intention of this feature is to make it easy for web developers, and even non-developers, to utilize their contact’s data to personalize a landing page. For example, you might want to show the contact’s name or pre-fill an address box using the contact’s details.
When you use this feature, however, Infusionsoft will add several pieces of information to the end of the URL even if you don’t plan on using them, including the contact’s email address and password. Anyone who clicks that link will easily be able to look in the address bar and find your contact’s personal information. If your contact forwards the email to a friend, then the friend now has the contact’s password. Since most people re-use passwords, this can be a very serious security issue for your contact.
Even if the email isn’t forwarded, the URL along with the contact’s personal information is transmitted in plain text unless the link is pointing to a site using HTTPS. This means your contact’s password could easily be stolen (for example, if the website publishes their logs or if the user is on an open WiFi connection).
The solution to this problem is to include only the information you actually need in the URL. You can easily do this using merge fields. For example, if you wanted to link to https://novaksolutions.com/ and you wanted to include the contact’s first name, you should make sure the “place the person’s details at the end of the URL” box is unchecked and change the link to something like this: https://novaksolutions.com/?FirstName=~Contact.FirstName~. Infusionsoft will replace the merge field with the contact’s actual first name.
Does it take a little more effort? Yes. Is it worth it? Absolutely. Nothing is more important than your contact’s security.
Great tip. (as usual)
Great tip, Jacob.
Related to this is also the desire to remove the inf_contact_key field from URLs. Unless the link you’re sending them to is another Infusionsoft hosted Web Form, an order form or shopping cart, there’s practically no purpose of this being appended on the URL.
You can disable this setting, or more accurately enable it only on Infusionsoft.com URLs by going to Marketing Settings > Email Defaults > Scroll to the bottom and change it as you desire.
Example:
http://i.imgur.com/D4wjuQK.png
The issue for me (that I’ve witnessed) is that these URLs are all unique hashes of the Contact ID. When pointing them to say a WordPress site, it causes the server to serve up a unique page for every visitor unnecessarily. Effectively, this voids any performance gains one might have with caching plugins, Vanish or other performance strategies to improve performance unless they are making use of Cloudflare or another DNS proxy.
As far as I know is that at this time, it is not yet possible to take action with these contact keys. Therefore, I believe the benefit is limited to only Infusionsoft domains.
Anyhow, this is good advice for users to improve the privacy and security of their contacts via email and links. Keep it up! 🙂
-Joe
Great tip! Thanks!
What I always thought regarding passing field data from an email link to a URL was that it will only pre-populate fields or hidden fields if the form is an Inusionsoft hosted form. I think that’s what Joe is saying, correct? Otherwise, php is needed or Jeremy’s url params WP plugin.Is that correct, Jacob?
Correct, the fields will only pre-populate a form if you are using an Infusionsoft form or are handling it on your own using PHP or a plugin.
What Joe is saying is that the inf_contact_key only works on Infusionsoft hosted pages. There is no way to use PHP or a WordPress plugin to utilize this key, because Infusionsoft hasn’t told us how to decode it. Letting Infusionsoft add it to your URLs will prevent caching and proxy servers from being effective, because it will essentially create a unique URL for every contact.
Got it – thanks for the clarification, Jacob.