Would you like to know if an email is generating way more clicks to the unsubscribe?
I ask because you're right about the clicks counting towards your click-through rate but I personally would find the information valuable to see how many clicks are generated by an email to the unsubscribe.
To remove the tracking would be to remove this piece of the puzzle. If the clicks to the unsubscribe are skewing numbers, then you might have a bigger issue than just reporting semantics
Does your ESP provide a heat map of clicks to help tell the story?
I use another example for myself to keep things in perspective
If I send an email to 500,000
2 people open, 1 person clicks
My unique click-through rate is 50%!
But this was clearly not an effective email
I personally have the unsubscribes tracked and keep an eye for abnormal spikes in clicks to the unsubscribe link via the heat maps
We also use snippets and save them in Dreamweaver that we regularly pull from and access
We have a team of 4
This could be looked at differently - I personally rely on our training and QA process
Any new team members build an email from scratch following along a foundational framework so they get the gist of how the code works and why it does what it does. It allows them to immerse themselves and really understand what's happening instead of just knowing it works.
Then the library of snippets is maintained by a lead generally and we add any new functionality with a brief description. We don't want chaos of everyone updating the core code.
When it comes to using the snippets, it's knowing how it works and what to use for a particular piece of an email - 2col stacker, 3col stacker, full-width fluid, etc. As long as the email renders properly across all clients using our Litmus preview and internal testing - we are comfortable with how it was coded by the individual.
Of note, our designers are required to code as well. This way what the design is within the means of how code works. We always push for innovation but it's important for a designer to know how it will be coded - it makes a difference.
A lead (who did not code the email themselves) will always QA an email before it is passed along to review by the business. The QA process is ensuring the end result is correct - the email renders properly across all clients and functions as expected.
Our workflow is meant to prevent duplication - 1 designer works with the business, 1 coder works on coding, there are approvals along the way to prevent swirl/confusion. We use JIRA to log the work throughout the workflow and document what work is done along the way.
Do you use a workflow and/or ticketing system?
Is any of this helpful?
One of the important pieces is "disabling" outlook from doing the flip - it creates this ghost line that cannot be removed
Disabling outlook shouldn't be an issue, it will just have image left - text right , repeated and still look nice
Just taking a brief look at the code - I would check your second section, with the image of the computer
that whole section has fixed widths - 600px, instead of percentages
because the widths are being defined, the image and section are not resizing and thus makes mobile look funky
there are multiple ways to approach them but I would suggest at the least
Hope that helps