凡新涉SFMC者，其始皆同。客以四十列之Excel表载客户数据，告曰："此导入于SFMC。"团队乃作一数据延伸，以应Excel之列。两星期后，此延伸不能发邮件，不能与他延伸相系，且有一字段因数据类型之谬，不得导入。
其解，在于延伸未成之前，先定四决，非成之后也。
决断一：此DE为何用？
- 可发送之DE：将用于发送邮件。于属性中勾选“可发送”。须有类型为电子邮件地址之字段，并具订阅者密钥之关联。
- 查询之DE：存储AMPscript于发送时查询之参照数据（销售代表名单、产品目录、店铺位置）。不可发送，无需电子邮件地址。
创之先择。既成而后增"可寄"之性，虽可为之，然烦扰；于既有之DE含数据者，正"订阅者键"之关系，易生谬误。
决二者：主键何在？
主键者，独辨每条之列也。规：
- 必遍历DE中诸记录而唯一。
- 发送之物，当用系统之标识，如 CustomerID 或 MemberID。勿用 EmailAddress——一人可有多邮箱，且人恒易其址。
- 查索之物，当用本然之标识，如 SalesRepID、ProductID。
决第三：何项可空？
- 非空者，谓此项必具。若导入之列阙之，则弃此列。
- 邮箱地址与主键，几近皆不可为空.
- 人口统计之项（住址、电话、生辰），常可为空，盖因源数据非必完备.
载入满布空缺不可为空之项之文件，而惑于半数之行消逝，此乃初周之常谬.
决断四：数据之型是否当适？
數據類型用於文字名稱、混合數字符號ID、地址數字ID、點數餘額電子郵件必須用於電子郵件欄位—SFMC驗證日期格式生日、到期日（格式必須與導入時一致）布林標記如VIP、已購買十進位金錢數額、任何帶有分數部分的數值
經典導入失敗：OrderNumber值如ORD-00123導入至數字欄位。字母使其失效。用文字。
审计中犹见四谬
忘设可发送
DE于发送时，受众选择器不显。编辑属性，勾可发送，配置发送关联。创制时决断，可免此患.
以EmailAddress为首要键
客更其邮。导入行。旧行存旧邮。新行增新邮。一人今为二录。观者数谬.
用恒定之系ID。邮非其身，乃属也.
一DE内二邮址型字段。
SFMC不允許同一DE中存在兩個數據類型為EmailAddress的字段。若Email Address與Secondary Email均被設定為EmailAddress，則自此DE發送的郵件將完全失敗——無人能收到。
此二者中必有一者需被設定為純文本。
字段長度過短
设全名长度为五十字，初看似宜，然有长名者，或遭截断，或被拒之门外。其果有二：
- 数据之完整：默然失之。
- 导入之速：若字段长度得宜，SFMC可速之。
量字段之长，宜取其至实之极，非取其中数。
自既有者而创之之捷径
若需新设数据扩展，其结构类同既有者（如VIP客户群，取自客户主表之字段），当于内容构建器中择“依既有创建”。>数据扩展。此法全袭旧式：字段名、类型、长度、可空标志皆悉数移用。惟增删异同之字段而已。
依模板造者，乃SFMC之预设架构（如触发发送DE、追踪DE等），非汝自造之DE也。异工也。
便当
点击"创建"之前，须决四事：其用（可送/可查），主键，可空字段，数据类型。三十秒之思，可省日后重建之功。若承继半废之项目，其共病之源，必在此四者之误。
启SFMC之项目，若源数据纷乱乎？吾Salesforce之团队，于生产协作中，设计数据拓展（Data Extensions）与数据模型也。相接>
睹吾等之全貌平台之务吾所论之栈也。