Monthly Archives: December 2010

防止邮件被Spam — Plain Text or HTML: Which Email Template Type Should You Use?

http://www.comm100.net/email-marketing-tutorial/plain-text-or-html-which-email-template-type-should-you-use.html

Plain Text or HTML?

Which email template type should you use?

In This Article…

If you’re beginning an email campaign and aren’t sure whether to use a graphically-based html email template to improve the visual appearance of your email or a plain text email template to improve the deliverability of your email (and conserve resources), this article lays out the pros and cons of each type. Comm100 will then give you advice on how to optimize your email marketing metrics through template formats and displays.

What is Plain Text Email and HTML Email?

The first thing that you need to understand is “What is plain text email?” and “What is html email?” HTML email is an email that is formatted like a web page, using colors, graphics, table columns and links. Imagine any newsletter that you receive from a service. That’s most likely what an HTML email looks like. A plain text email is an email that only includes text. Imagine your typical inter-office email communication. That’s what a plain text email looks like.

Email marketers generally don’t debate which format is better. HTML email converts better in marketing tests almost every time. However, there are some factors you should consider before deciding which mail format to use. Ultimately, there’s a solution to getting the best part of both worlds.

HTML Email

HTML email does, in fact, come with some problems attached to it. It’s an imperfect science, and you should be aware of ways in which html email can fail.

          –  Spam: HTML email can put you in the spam folder if your code is sloppy. Email providers’ spam filters look for code that looks like it’s been copied from a Word document, and they increase your spam score based on that.

          –  Coding Time: HTML emails are also harder to code than html pages. They need to be coded to appeal to spam filters, and to use css in very specific ways.  In some cases, you’ll even need to use different html email templates to send to different providers in order to make your email look consistent in all email clients.

          – End User Display: Some email providers (Gmail, particularly) will strip out many elements of your html email code regardless of how well it’s built. So no matter how many hours your developer and designer spent making your email look amazing, it may still end up as black text on a white background with blue links.

          – Image Blocking: Almost without fail, the majority of your end users will be reading their email with their images turned off. Therefore, every image that you used in your html email will be invisible to them. That means that there will be lots of dead white space in their email instead of colorful, inviting sales or informational text.

          – Mobile Phone Users: Up to 20% of your end users are reading their email on their mobile phone. Your html email won’t display at all on many phones.

However, it’s important to keep in mind the benefits of html email.

          – Better Visual Engagement: You only have a fraction of a second when a user opens an email for them to decide whether to read it or immediately delete it. The use of color and interesting visuals can keep them interested long enough to read and become interested in your message.

          – Better Information Organization: Most messages are not best delivered in a chunky text paragraph but instead in bulleted lists, columns, table layouts and a variety of text justifications. Also, differentiating words and concepts with color makes it easier on the reader to identify the important parts of the email. This can’t be done with plain text.

Pros and Cons

If you wanted to break it down into an easy theory to remember, it would sound like this:

Plain text email is better if

          – You are incredibly worried about deliverability into the inbox

          – You are expecting replies to be sent to your email

          – You are concerned about making sure your email visuals do not break or appear incorrectly in email clients

          – You don’t have the development and design resources to create a well tested, tightly coded html email template

HTML email is better if:

          –  Your main objective is to convert a sale

          –  The information you are presenting needs to be visually organized

          –  You have the in-house resources to create a workable and successful email template

          –  And, most importantly, you can send a plain text version as well (see below)!

Send Both!

The best solution if you want to send an html email is to send a plain text version attached. The plain text version will then display in instances where the html version can’t load. For example, the plain text version would appear in many mobile phone scenarios and often certain Outlook clients. Many third party email providers offer this option as a default option. In fact, some of them even require that you enter a plain text version along with your html version before they will allow you to send. In this way, you will get the benefit of displaying color, graphics and format to those who can see it without prohibiting your other users from reading the message.

If, however, you’ve only got the capability to send one option or the other, Comm100 suggests you review the pros and cons above and then decide which is best for you. It won’t be the same answer for everybody!

Whether you’re sending a bells-and-whistles html email or a stripped-down plain text email, whom you use for your email provider is the first step in creating a successful campaign. Comm100, who provided you with this complimentary summary of the pros and cons of different email types, offers a completely free, hosted email marketing and newsletter solution. It’s both a great long-term and short-term solution to getting your email marketing off of the ground whether you’re sending html art or simple plain text! Check it out at http://www.comm100.com/emailmarketingnewsletter/.

倒底要不要使用Bind Variables

为了避免硬解析(即为了实现游标缓存),应该使用Bind Variables。这点大家都知道。

然而, Bind Variables如果出现在where子句中,它就会减弱查询优化器的某种能力:根据统计信息和SQL中的字面量选择最优的执行计划。  比如说,假定当前表里的age大都是50岁以下。如果SQL里指定了按 age<50 来查询,那优化器就会来一个全表扫描,快速返回相应数据; 如果SQL里使用的是 age < :age1,那优化器就不敢轻易走全表扫描了 (11g里部分地解决了这个问题,在此不表)。

那倒底要不要用Bind Variables呢? 《Troubleshooting Oracle Performance》给出的方案是:

  1. 如果Bind Variable并没有出现where子句,那就没有理由不用它

  2. 在小量数据查询环境下,如
OLTP中,硬解析的时间与执行时间相当甚至更大,
应该使用Bind Variable,避免硬解析

  3. 在大量数据查询环境下,如
OLAP中,硬解析的时间与执行时间相比只是一个零头,
这时就应用直接用字面量,以免查询优化器选错了执行计划

软解析、硬解析及其对性能的影响

SQL解析时要经历以下几个步骤:

   1. VPD相关处理

   2. 语法、语义、权限检查

   3. 对SQL进行逻辑优化

   4. 再进行物理优化

这其中会牵涉到游标的缓存读写: 看下缓存里有没有所需的游标,有就读出来直接用,没有就要创建一个出来用,用完后塞到缓存中。

如果缓存已存在,那就只需执行上面的步骤#1和步骤#2。 这就是软解析。

否则,就会执行所有步骤。这就是硬解析。

由于步骤#3和#4比较耗费CPU,而在缓存里创建新游标又比较耗内存,因此硬解析比软解析的开销要大很多,因此应该尽量避免硬解析。

要避免硬解析,就得尽量重用缓存中的游标。而游标是以SQL为Key的,要重用游标,就要尽量对同样的操作使用同样的SQL(大小写、空格都要一样),也就是说要用Bind Variables.

============================================================

不过,软硬解析代价都其实都很高,因为它们都会产生对共享资源的竞争使用。 Oracle中,这些操作的并发性达到了“可串行化”级别,对性能的影响很大。