I publish myself as a personal teacher for students, and recently the number of the clients increased, and I think that a proper solution for me will be like that:
when a client sends me an email on Gmail (more correct, puts my gmail address on "send to" field), a template will show up and the client will choose from dropdowns details like: grade, subject, phone number etc.
and that will help me manage myself in a proper way.
I would like to know if that possibility even exists on gmail, and if it does, how do i operate it.
thanks for helping me.
The closest thing that I can think of is using Filters. Filters in Gmail will let you label incoming mail based on the sender, subject or more. These will then show the label in your inbox. You can then keep a Draft or spreadsheet of response templates. You can read up more on filters here.
Related
I've implemented List-Unsubscribe (RFC 2369) for marketing emails we send. I am providing both an unsubscribe email address and an unsubscribe URL. An example of a generated header looks like this:
List-Unsubscribe: <mailto:unsubscribe#myserver.com?subject=unsubscribe>, <https://myserver.com/unsubscribe?email=recipient#email.com>
In the past few email campaigns we've done, it has worked great. There's only one problem. Sometimes we receive unsubscribe requests from email addresses we didn't actually send mail to. I think this happens when the user has multiple email addresses and the email we send is forwarded to some other destination. So we send to user-a#email.com, but the recipient opens it at user-b#email.com. When they click the "Unsubscribe" link provided by their email client, it generates an email to us telling us to unsubscribe user-b#email.com.
Sometimes we can find the intended address if the address we sent to was very similar, or if the user has a unique name, but sometimes it's impossible to determine which email address we should unsubscribe. That's frustrating because we know the user will be upset if they receive another email from us in the future.
I tried to fix this by adding a unique identifier to the subject line, so that a subject looks like unsubscribe_20934832034820348, but when we do that, email clients stop showing the Unsubscribe button. It's as if they will only show the Unsubscribe button if the subject line is exactly "unsubscribe".
I didn't see anything in the RFC about the subject line needing to take a particular form, and we are also taking care not to put the user's email address directly in the subject line. (It is a hashed combination of their email address and a portion of the original message, making it unique across all emails we send.)
Is there some sort of convention around this? If so, how can I reliably determine the original address we sent to when we receive unsubscribe emails?
It looks like there is no problem using this sort of subject line. However, it seems that each email client decides in its own proprietary way when and how to display the Unsubscribe button/link, and it does seem that that when you change from a simple "unsubscribe" to "unsubscribe" plus some unique identifier, some clients might subject you to some sort of test period before showing the link to users. In my testing, Gmail did not show me the link when sending small batches of test emails, but after I sent a large batch of emails, the link did start appearing, and I did indeed receive the generated unsubscribe mails properly.
I hope this helps someone out there.
I manage an email newsletter for a customer. It uses a custom list management utility, but the emails are being delivered through SendGrid.
In order to integrate correctly with our list management unsubscribe. I'm manually creating the "List-Unsubscribe" header, with a mailto address, which goes to an email parser, and unsubscribes the user from the correct publication etc.
The email parsing etc. works fine. However for some reason gmail is not displaying the "Unsubscribe" link in the header, as it does with other newsletters I receive.
Another newsletter I manage for a different customer, uses SendGrid's built-in unsubscribe management, and for these ones gmail does display the link.
What I want to know, is why is my custom "Unsubscribe-Link" ignored by gmail, but SendGrid's works?
SendGrid's "List-Unsubscribe" looks like this ...
List-Unsubscribe: <mailto:unsubscribe#email.mycustomdomain.com?subject=http://links.mycustomdomain.com/asm/unsubscribe/*q*user_id=[SHA hash...==]>
My custom "List-Unsubscribe" looks like this ...
List-Unsubscribe: <mailto:u-[custom-encoded-user-id+publication-id]#list-management.mycustomdomain.com>
My email parser reads the incoming "to" address, and interprets the encoded user-id and publication-id, to unsubscribe the person from the correct list.
Can anyone suggest why gmail might not like my link? It's extremely difficult to find detailed information about the requirements for this header.
One obvious difference, is that mine doesn't have a subject, but that's because it doesn't need it. It gets all it needs from the "to" address. Could this actually make a difference though? Does the "to" address need to remain static?
I thought perhaps it just needed time, for gmail to familiarise itself with this newsletter. However it has been running for months, and still no link.
The list is very clean, and all recipients have opted-in. We don't get any spam reports, and very few bounces.
I've gone to a great deal of trouble to ensure that everything works correctly from my end, and it's very frustrating that I cannot find out what I need to do to make this work.
I found a similar question at the gmail forums, and the official response to that question was to "contact a professional about constructing html emails".
Not very helpful for me, as in my case, I'm supposed to be that professional.
Any suggestions would be greatly appreciated.
I'd like to send an email message that contains multiple translations. The correct translation should be displayed according to the recipient's language preferences. Possible?
There is nothing in the email message format that will let you do that. What you can do instead, is to put translated contents as attachments, or post some (translated) links to your website, that will refer recipients to translated contents.
Anyway, I think it is best to store language preferences in the user profile (provided you have one) and use this information for customizing emails. That works well, unless you are sending messages to group of people...
To the best of my knowledge, email accounts are protected from getting any information about the recipients unless they provide it. Even email clients often prevent emails from displaying pictures, since it reveals the recipient's IP address. So I also think, it's unlikely to be possible.
I agree with the idea of Pawel Dyda.
What is the best way of tracking responses for email campaigns? I was thinking on adding something to the reply-to field of the email (for example luqita+campaigns#stackoverflow.com), but I'm not sure if there is something more neat that could avoid this?
I thought about headers too, but it's important to note that the address luqita#stackoverflow.com would send many different campaigns, and the 'in-reply-to' header info would not be useful then to differentiate (while using luqita+campaign1 or luqita+campaign2 could)
What can I do?
So you want to be able to execute some logic when someone replies to an email you have sent through SendGrid? If you have access to change the MX record of the domain of the email address at which you want to receive the replies, you could use SG's Parse API to get a POST request to a script whenever email is receive at the address.
I think you would indeed have to set a magic reply-to address for each campaign. This seems like a perfectly fine solution; it's also how SG itself tracks bounces - it sets the return-path to something like bounces+{attempted-recipient-email}#sendgrid.com. Then examine the 'to' parameter of the POST notification you receive to know which campaign the reply is associated with.
When you say "tracking responses", do you mean that you expect users will reply to the Email, or do you mean that they'll click on a link in the Email and interact with a web site?
SendGrid obviously offers click tracking and open tracking, and you can set up to 10 different categories for tracking campaign stats and see delivery/bounces/opens/clicks/etc based on those categories. They also have a Google Analytics plugin that can feed back some analytics data to Google. And as #LinusR mentioned in his answer, the SendGrid Parse API can be set up in a way that reply Emails can get parsed and posted back to your site.
If the user will be interacting with your web site, you can use the "unique args" setup at SendGrid to set a unique string/hash to append to any URLs that can help identify a particular user, campaign, or whatever else you want to track.
I'm generating a bulk mailing each day for users who want to receive the daily deals. I can either send a separate physical email with each user specified on their own unique To header, or I can send one email with all the users on the BCC line.
Obviously if I ever want to create user specific content I will need to customize the emails per user and send them individually, but if I don't want customized email right now, should I just send out the single email with everyone on BCC? Any reason to NOT do that.
Edit: I'm using a third party as my gateway that specializes in delivery with CAN-SPAM compliance, etc.. not trying to do this off my own mail server...
Update: I guess I'm really also looking for some metrics here. Is there a difference in open rates of BCC'ed email vs To field email? What about spam filtering rules that might pre-classify based on the BCC field?
No reason I can think off for NOT doing it. Using BCC is the polite way to send bulk emails.
In this case, it turns out that the correct answer was neither. The gateway provided a custom header API that allowed me to specify all the recipients in a secondary "To" field. The API then handled the blind delivery of the emails, and also did variable substitution for me so I didn't have to transmit all the duplicate content multiple times. The API then handled doing "best practices delivery of the email".