TL;DR:
Tracking clicks on links in email via third party mail sending systems (SendGrid or Mailgun) has become so problematic these days that this function needs to be moved into Rock itself.

Rock has all of the building blocks to do this already in place, namely Communications (duh), Short Links and Email Analytics. All that needs to happen is for the Communication Wizard to be wired up to rewrite any links in a communication to a Short Link on the way out, and then have clicks (Interactions) to those Short Links surfaced in the Analytics for that communication.

In this way, Rock does all of the heavy lifting and "click tracking" within itself, not relying on a third party to do it at all. Perhaps a new lava command or other markup could be added to wrap around only the links the sender wants to be click-tracked, and other links would be left alone? (this would keep the Short Links from growing with every little link in an email that might not be interesting to track)

In my opinion this is becoming necessary because...

Long version:
For many years now we've been able to configure "click tracking" of links sent in Rock communications via mechanisms provided by SendGrid and Mailgun (aka mail sender). This feature can typically be enabled in one of two ways:

1.  Mail sender sees the links within the Rock communication and rewrites those links to a format such as

https://something.sendgrid.net/oyuiwqhjksadfnm

and when these links are clicked by the recipient, the mail sender takes note of the click, redirects the client to the real link, and tells Rock that link was clicked via a webhook.

2. Pretty much the same as #1, except you can "brand" your links to be something like 

http://link.yourchurch.com/oyuiwqhjksadfnm

the obvious advantage here being that the links are branded to your organization's domain and are thus theoretically more trusted, and just look more legit. People are being taught over and over today to "hover over the link" and make sure it's going where you think it is, thus making these far more preferable to unbranded links via #1.

The problem with #2 type links is subtle... notice that http was used in that link instead of https... this is necessary because an organization cannot give SendGrid or Mailgun their TLS certificate for https links to their own domains. Sendgrid cannot "host" the links at https://link.yourchurch.com on their own website because it doesn't have your certificate. That's why option #1 that uses UNbranded links can use https... because they of course can secure links to their own websites.

So now you're thinking "So what? Http still works, and securing these click-tracking links isn't really necessary, so what's the problem?"

The problem is that more and more each day, browsers, browser plugins, and/or "security" software running on the client machine that just received your email will "help" you by automatically turning any http links it sees into https links (aka "elevating" your links), purportedly to enhance your security.

Now the client clicks your pretty http://link.yourchurch.com/lskdflksj link in the email and is presented with nasty error or warning that the link is not secure and unsafe because there's no valid TLS certificate for your domain at the mail sender when all you were trying to do was take note that a link was clicked. Sigh.

So that's why this functionality needs to be moved into Rock itself (see TL;DR above). By doing this:

- All click-tracked links in your communications sent from Rock would be from your own Rock instance, and thus more trusted.
- They'd be https links, making browsers and security software happy
- You wouldn't be giving this click-tracking information to third parties and everything would stay in Rock.

Depending on cost we'd be able to fund at least part of this. Maybe others organizations that find value in such a feature could join in?