BoostCE: 2018

Friday, December 7, 2018

Friday, November 30, 2018

Friday, November 23, 2018

Friday, November 16, 2018

Friday, November 9, 2018

Friday, November 2, 2018

Friday, October 26, 2018

Friday, October 19, 2018

Thursday, October 18, 2018

What is an Email Honeypot?

According to Wikipedia, "Honeypots are a vital piece of computer security - designed to detect, deflect or in some manner, counteract attempts at unauthorized use of information systems."

Did you know there are Email Honeypots?

Email Honeypots are designed to find people who are using bad practices in their mailing.

At the heart of them, honeypots are spam traps. Your email will look like it's delivered, but the ESP at the other end is taking notice. (There's even a honeypot network to share information and more quickly identify people who are emailing honeypots.)

Quick reminder:
ISP = Internet Service Provider (recipient - Gmail, Yahoo, AOL, etc.)
ESP = Email Service Provider (sender - ExactTarget, MailChimp, etc.)

What Happens if I Get Caught Sending to Honeypots?

Mailing honeypots is bad news. Do it enough, or email enough honeypots and you may find your email dropped into the spam folder, silently discarded by the ISP or outright bounced/rejected.

How Do I Know if I Have Honeypots on My List?

That's the thing. You won't know. But, if you practice good list hygiene and good acquisition practices, you will greatly reduce the changes.

How Do Honeypots Get on My List?

One type of honeypot is the "lapsed address" - this was an address that actually belonged to someone. But, they've stopped signing in and the ISP now considers the address "abandoned." If the ESP sees that the email address gets a lot of email (signs that the address has been sold or stolen from other websites via hacking), it will reject all email to that address for a period of time, and then start accepting the mail again.

Another type is the "intentional honeypot" - this address was created for the sole purpose of being a honeypot. After it was created, it was placed on a website where it could be scraped or otherwise discovered. It may be intentionally submitted to list brokers.

The third is the "injected honeypot" - this is pretty rare. Hackers have intentionally inserted the honeypot email addresses into poorly guarded databases. Once an email goes out to that list, they have more information about who owns the database.

How Do I Avoid Honeypots?

Being a responsible emailer!

Don't Email Old Addresses - if you have an address on your list that you haven't emailed in 6-12 months after you acquired it, proceed with caution. Attempt to verify the email address using a third-party service. Keep in mind that they honeypots look like regular functioning email addresses, so this may not protect you. Don't collect email addresses unless you're going to use them, don't try to send to old addresses.

Remove Bounces - Most ESPs will automatically remove/suppress bounced addresses for you automatically. Make sure you understand the your ESP's policy regarding bounces and suppression, paying special attention to any places where you have the ability to override suppression rules.

Don't Buy Lists - These are notorious sources of spam traps, bad addresses, invalid domains, and so forth. The quality of these lists are horrible and despite any sales pitch, no one ever opted-in to receive any random email from anyone and everyone who wanted to buy their name. No one's giving that kind of permission, these addresses were probably scraped off a website or swiped from a poorly secured database.

Protect Your Databases - Don't leave unsecured lists anywhere, don't send unencrypted data in Excel for a text file. Just be smart. You don't want this stuff stolen or sold and you don't want extra surprises added to it either.

Friday, October 12, 2018

Friday, October 5, 2018

Friday, September 28, 2018

Friday, September 21, 2018

Friday, September 14, 2018

Friday, September 7, 2018

Tuesday, September 4, 2018

Why Do Email Developers Hate Outlook?

Every so often someone will ask "Why do Email Developers Hate Outlook?" and then follow-up with "But... Does anyone still use Outlook?"

To answer both questions, let's examine about what "Outlook" is.

Outlook.com is the web-based client that replaced/consolidated Microsoft's previous Hotmail.com, Live.com, Start.com and MSN.com mail offerings. There is also a web client for Outlook for Office 365, but it's pretty much the same as Outlook.com in how it functions and renders. Outlook.com has its roots in Microsoft Office Outlook Web Access and Microsoft Office Outlook Mobile Access, an impressive engineering feat with what it offered on the web long before anyone else.

And Outlook is a web app available on Android and iOS. They use the built-in rendering engines for those platforms, so typically any rendering oddities will also be seen in the stock Android and iOS Mail apps. (Gmail and Samsung have their own issues. Gmail alone could be a whole separate article.)

Outlook is a desktop client on the Mac. It uses the MacOS webkit rendering issue and emails look as beautiful as they do in the standard Apple Mail client. Outlook replaced Entourage and was available in Office 2011 and 2016.

And then there's Outlook on Windows. There's Outlook 2000, 2003, 2007, 2010, 2013 and 2016. These use Microsoft Word as their rendering issue, not the various rendering issues (MSHTML, Trident, Spartan, EdgeHTML) that Microsoft has released with its various Windows versions over the years. The Word rendering engine doesn't support all of the modern CSS (or even HTML) commands, and then introduces a few of its own.

And, lastly, there's the oddballs - Outlook 2013 120-DPI which upscales fonts and images -- and an accessibility option in most versions of Windows to change all fonts displayed to make them larger than everything else on the platform.

There was also Outlook Express, a Windows app that shared the name but little else beyond also being an email client. Windows 10 also offers Windows Mail. And then Windows Mobile also has its own mail client. These are still distinct but are rarely used.

Which leads to the question "But does anyone still use Outlook? And if so, why??!!?"

Outlook is still well-used in the business world. The fact that Outlook on Windows shares its underpinnings with Word means that if you can see it in Word, you can see it in Outlook. This includes Excel spreadsheets and charts, PowerPoint slides and custom applications written by large organizations for their own use. (These are the places where it's nearly impossible to get a Mac and if you do you'll still have to use BootCamp or a company-issued PC to interact with some applications.)

Of course, changes to Word and Office over the years, plus these Word-specific inclusions and exclusions leads to lots of bugs when it comes to trying to create emails that look good in Outlook.

Some people just don't worry about Outlook if their audience is small enough it's rarely as small as they hope). But, more often than not a lot of cool experimental features (the kind of stuff that it's fun to build and wows subscribers) not to mention some great design is dropped in order to make sure the email will still look nice on Outlook.

This is why it's important for designers to collaborate with developers for new email designs. And if you're hiring an Email Developer and they bring up Outlook (and you can't work in this field and not have Outlook stories), now you know. (And if you're hiring an Email Developer and they don't mention Outlook, you might want to keep looking.)

(cross-posted to LinkedIn)

Friday, August 31, 2018

Friday, August 24, 2018

Friday, August 17, 2018

Friday, August 10, 2018

Friday, August 3, 2018

Friday, July 27, 2018

Friday, July 20, 2018

Tuesday, July 17, 2018

Marketing Automation without Drag and Drop

A lot of companies want to sell you on their "Journey"-making programs - usually a drag-and-drop interface for creating Marketing Automation for their customers. Meet the criteria, we start to market to you. Based on how you engage (or don't), the journey changes. It's really cool - it looks great, it makes people salivate, and usually the people selling the product have created an amazing example.

from centricconsulting.com

Unfortunately, reality is that Journeys are difficult to build. Evolving business requirements, realities of a changing marketplace, reporting complexities, difficulties diagnosing issues when people enter (or are dropped) from journeys when they shouldn't are just some things the practitioners face when they try to actually implement and maintain journeys.

Some platforms offer SMS, display advertising and other methods of engagement exclusively in their journey tools. Since everything I've worked on to date has been exclusively email-based, I have eschewed these pretty tools in the various places I've worked to implement marketing automation.

I will still draw out diagrams like this on whiteboards when planning out what we want to do. Once we're satisfied, I'll sit down at a far-less graphically-oriented tool to start building out the vision.

This gives me a lot more control, a lot more visibility into the inner-workings, it makes it easier to tweak things as we go, but it also means a lot more of housekeeping is also up-to-me to keep clean if I want anyone else to partner with me on the work, or if I want to be able quickly jump in weeks or months later and make changes without having to spend a lot of time trying to remember what does what.

So, I've been working to refine a standard naming convention and process flow for moving people through the process. In some places, this may seem like overkill, but it's all borne out of years of refinement.

For each step of a process, I will take people through a standard process which includes a standard naming convention for tables.

A (Import) - this catches new people entering the audience. This can be from an FTP import, a filedrop, or an API. The naming conventions for the fields (or indeed the entire schema) may be determined by an outside source outside of my control.

The automation starts here....

B (Batched) - this is where an audience is batched. New records are brought into B and then A is cleared. I have full control over the schema and field names for B. If there is additional data that I need, I may have one or more queries that add additional information to the records in B.

C (Cleaned) - because the tool I work with only allows use of the SELECT SQL statement (no DELETE), this is how I remove records I don't want. I copy over only the valid records from B to C. Then I immediately copy the records back to B. Now B contains the valid, ready-to-go audience.

V (Validation/Verification Needed) - if the quality of the incoming audience is suspect, I may set new records aside for verification or validation with a tool like Kickbox. After validating, I can drop the records back into the B table with a flag set to either indicate verified-ok-to-use or verified-bad (in which case the subscriber would be dropped the next time the records are cleaned.)

Sometimes the automation ends here and a second automation handles the rest of the program. This is important in high-volume settings.

P (Prequeued) - optional, not shown. I use this when I only want to pull out a subset of my overall eligible audience. I do this when I want to spread out a send over a longer period of time, instead of just sending all eligible right away.

Q (Queued) - this draws forth an audience. It's been segmented to the people you want to have in the cohort. During testing, you can constrain email addresses only to your domain or set it to only grab 5 or 10 people. In the event that you need to very quickly prevent anyone from entering an automation (effectively a pause without touching the automation itself, add a nonsensical bit of SQL criteria here) like "AND EmailAddress = 'this-will-never@match@anything.com'"

You can stop the automation here if Q is empty. No need to send blank emails.

Sn (Sends) - Divide your queued audience into one or more sends. You could split into two or more audiences to test, or you could take only a subset of Q in order to test whether it's better to send an email or not.

...something else goes here (described below)....

T (Sent) - This optional step brings all the Sn audiences back together. This is great for troubleshooting, or if you want to do anything based on the difference between Q and T (who didn't get sent, who was suppressed, who was dropped by the ESP, etc.)

X (All Sent) - This optional file captures everyone who was sent, drawing from the Sns or from T. This may be useful in research/reporting, especially if you didn't send to everyone who was eligible.

Z (Suppression) - Bring back everyone who was in the audience. In a lot of these treatment streams, you only want them to get the email once. By placing them here after the send, you now have a nice handy file you can examine in SQL queries or place as a suppression on the time-of-send instructions used by your ESP.

...but wait, there's more... so I skipped a step up there after Sn - the actual send. This is where you stick the instructions for the sends. This nice thing about this methodology is that you can add them later. You can run this automation hundreds of times to make sure everyone is flowing through correctly (using live data) without ever actually sending an email. Once you're satisfied, clear out your Z file, set your Q query to only allow your corporate domain in, add the sends, and start up the automation and watch it go to your coworkers and colleagues. Once you're happy, allow it to go to everyone.

So how about naming?

Name all your folders the same, whether they hold tables, queries, automations or email. That way, it's easier for others (or yourself in two months) to navigate.

I like to name my tables like this:

welcome0_a_import

welcome0_b_batched

welcome0_c_cleaned

welcome0_q_queue

The lettering scheme helps keep them in alphabetical order.

And I like to name my queries like this:

welcome0_01_a_to_b_bring_in_new_records

welcome0_02_b_to_b_get_subscriber_status

welcome0_03_b_to_b_get_last_purchase

welcome0_04_b_to_c_clean_records

welcome0_05_c_to_b_replace_cleaned_records

The numbering helps keep them in the right order that they should be placed in the automation (helpful in QA, a pain if you add steps). Also by indicating the source and target audiences (b_to_c) it makes it easier to follow the path of data, especially as you're incrementally building and testing.

This also makes documentation easy because a lot becomes self-documenting.

Friday, July 13, 2018

Friday, July 6, 2018

Friday, June 29, 2018

Friday, June 22, 2018

Friday, June 15, 2018

Friday, June 8, 2018

Friday, June 1, 2018

Ugh. @microsoft is awful.

Dealing with some deliverability issues with Microsoft. They give you the run-around for awhile, and then reference this document:

enhance_deliver.pdf

Only it's clearly not a maintained document and littered with problems. Just the ones I've spotted so far.

Page 6, step 1, Guidelines - bad URL:
https://sendersupport.olc.protection.outlook.com/pm/Guidelines.aspx

Page 6, step 2, Postmaster- bad URL:
https://www.microsoft.com/mscorp/safety/technologies/postmaster/default.mspx

Page 6, step 3, SenderID - bad URL:
https://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx

Page 6, step 4, Join the Program - bad URL (just goes to main page of MSN):
• http://support.msn.com/default.aspx?productkey=edfsJMRp&mkt=en-us

Page 6, step 5 - SNDS - bad URL (just goes to main page of MSN):
https://postmaster.live.com/snds/index.aspx

Page 11 - OpenRBL is now just some sketchy Chrome Extension.
http://openrbl.org

How on earth is anyone supposed to fix stuff if Microsoft isn't even able to properly help? (Of course, their other option is to tell you to go pay for ReturnPath.)

Friday, May 25, 2018

Friday, May 18, 2018

Friday, May 11, 2018

Friday, May 4, 2018

Friday, April 27, 2018

Friday, April 20, 2018

Friday, April 13, 2018

Friday, April 6, 2018

Friday, March 30, 2018

Friday, March 23, 2018

Friday, March 16, 2018

Friday, March 9, 2018

Saturday, March 3, 2018

ExactTarget Interview Questions

Last year I had a phone screening with a consulting firm that specialized in supporting clients using the ExactTarget platform. Since I'd been using the platform for many years in a number of capacities (direct contributor, manager over a team of developers, selected it in two RFPs at two companies, participated in several consulting sessions with not-yet-released functionality -- some of which I had recommended -- and even worked for a time at ExactTarget Professional Services), I was pretty embarrassed when I bombed their interview questions.

It did go to show how complex ExactTarget was, but I felt like all of their questions were about legacy pieces of ET that people should be doing everything they can to no longer use. I felt if I had had a chance to talk more about some of the complex solutions I had built -- some of which ET themselves said was impossible until I proved them wrong -- that it would have been a completely different outcome.

In the end, I finally had to write my own questions just to get that feeling of failure out of my head. I shared them with the consulting firm (not sure what they thought) and then had a chance a few months later to use them myself in phone screenings, including for my replacement.

The point of these questions isn't to provide an exhaustive list of everything you can do in ET. In fact, these were biased towards how we used the tool, and if you've used the tool, you know there's lots of ways to perform tasks (perhaps too many) and that every place uses it a little differently. But the point of the questions was to assess a candidate's experience with the parts of the tool we used and to see their thought process. I told candidates that I wasn't looking for 100% right answers, but I wanted them to speak freeform as they thought about their answers and to use personal experience from their own past projects wherever possible. I didn't ask all the questions, but as the conversation progressed, they helped me to aim at certain areas. I found it was helpful in getting nervous people to open up as well.

So, here are my questions. If I were looking to hire ExactTarget practitioners today, these are still the questions I'd start with. -- James

Explain the difference between Automation Studio and Journey Builder.
Name three ways to get data into SFMC.
What are some caveats to sending from Data Extensions?
What is the difference between update, add and overwrite on import activities?
What are the four ways Automations are started?
What are some of the built-in Data Extensions/Views in every SFMC account?
What does the Sendlog do?
Without looking at SFMC, explain as many parts of User-Initiated Sends as you can.
Within Automations, you can put multiple actions within a single step. Under what circumstances should you put multiple actions within a step? Under what circumstances should you separate actions into their own steps? Under what circumstances will SFMC not allow you to put actions in the same step?
What happens/can happen when there's an error in an Automation?
What are some limitations to working with images in SFMC? For the image size limitation, what are some ways you can mitigate? Name something else you need to consider when working with the new Content Studio, with regards to images.
What are the limitations for browser-based uploads and downloads? What is the solution to overcome that limitation?
Name three ways to invoke/initiate journeys in Journey Builder.
What are some of the things present in SFMC contracts? (Now that they're charging per contact, important for people doing solutiongineering to be aware of how their decisions will financially impact their customers ongoing.)
What does Validation do in Automations?