我正在为在线业务构建星型模式。关键流程之一是电子邮件通讯注册。
但是分析取决于两个过程，我无法弄清楚如何以最佳方式对其进行建模。
以下是该过程的工作原理：
- 人访问网站
- 人员填写网络表格并在我们的 CRM 中记录为联系人
- 人收到一个链接，要求他确认这是否真的是他的电子邮件
- 人单击链接并被视为已确认
- 人现在可以接收来自我们的电子邮件
注册和确认过程发生在不同的时间。大多数人在同一天点击确认链接，但我们会在注册后的几天内发送两封后续电子邮件，因此有些人可能会在几天后确认他们的电子邮件。
最重要的是，一个人可以在网站上注册多次。我们的大多数注册用户都是交换电子邮件地址以换取某种资源（如电子书）的人。
只要此人的电子邮件未在我们的系统中标记为已确认，我们就会要求此人在每次注册时进行确认。
由于我们有多个报价，因此一个人请求电子书 A、电子书 B 和电子书 C 并仅在多次注册后才确认的情况并不少见。
在事实表中，未确认的电子邮件的每个注册都标记为 ConfirmationRequested -> True。
如果此人单击任何确认请求电子邮件的确认链接，则应将其视为已确认每个注册。
我想如何分析数据
- 看看我们有多少注册
- 查看有多少注册是重新注册，有多少是 CRM 中的新联系人（新电子邮件地址）
- 查看有多少新联系人确认了他们的电子邮件地址（并成为正式订阅者）
- 查看有多少重新注册被要求确认他们的电子邮件以及有多少人这样做了
- 分析人们确认他们的电子邮件地址需要多长时间
- 分析确认率
- 按确认状态过滤联系人并分析已确认或未确认的人的共同点
我并不真正关心与注册隔离的确认。
出于我的目的，我希望有一个 ConfirmationStatus 维度，即...
- 如果此人在注册后 7 天内确认，则为“已确认”
- 如果此人尚未确认，但自注册后尚未过去 7 天，则为“待处理”
- 如果此人在 7 天内未确认，则为“未确认”（即使此人稍后确实确认）
除此之外，我通常会在周一查看这份报告，以分析前一周并将其与其他周进行比较。（我已经在一个平面表中有这个报告的工作版本，但我正在尝试学习如何构建正确的星型模式。）
这有一个额外的挑战，例如，周日注册的联系人只有不到一天的时间来确认，并且会降低确认率，如果与所有联系人都有完整 7 天的前一周相比，最近一周看起来很糟糕。确认。
因此，我计算了所有周的“注册周内确认”确认计数和比率，以允许苹果与苹果之间的比较。
这个怎么建模...
我考虑了以下选项...
选项 #1：单独的事实表 由于这些是在不同时间发生的单独过程，我了解到我应该创建单独的事实表，然后跨公共维度进行钻取。
我可以计算从注册表中请求确认的注册，然后通过联系人和日期维度计算注册后一周内的确认。
但这不允许我按确认状态过滤注册。
这就是为什么我正在考虑...
选项 2：结合注册和确认的事实表
我在想这样的事情：
| Dim Signup Info | | | Dim Contact | | | Fact Signups | |
|-----------------------|------|---|-------------|------|---|----------------------|----|
| SignupInfoKey | SK | | ContactKey | SK | | SignupDateKey | FK |
| SignupType | SCD1 | | Name | SCD1 | | ConfirmationDate | FK |
| ConfirmationRequested | SCD1 | | Email | SCD1 | | SignupInfoKey | FK |
| ConfirmationSucceeded | SCD1 | | ... | | | ContactKey | FK |
| ConfirmationStatus | SCD1 | | | | | SignupId | DD |
| | | | | | | SignupDateTime | DD |
| | | | | | | ConfirmationDateTime | DD |
| | | | | | | Signups | M |
| | | | | | | NewContacts | M |
| | | | | | | ConfirmationMin | M |
| | | | | | | ConfirmationDays | M |
事实上，我需要 ConfirmationDate 来计算报告时的“周内确认”度量（我正在使用 powerbi，这很容易）。我当然也可以创建一个维度“ConfirmedWIthinWeek”，然后根据它进行过滤，但它不会那么灵活......如果我稍后决定每天或每月查看数据怎么办？
另一个问题是它需要在过去 7 天的每个增量负载上重新处理和更新事实表。
我知道维度可以，但事实表也可以吗？
所以我的问题是
- 选项＃2是一个好的解决方案还是有更好的方法来做到这一点？
- 可以更新事实表还是不鼓励这样做？
总的来说，我的问题是：我错过了什么？
这似乎是一件很平常的事情。一个明显的例子是一个订单星，它具有 AmountOrdered、AmountPaid、AmountRefunded 的事实表列以及“Order Status”、“Paid Status”和“Refunded Status”等维度。
但是我的搜索都没有找到这个常见问题的答案。当然必须有一个问题的术语和解决方案的模式名称，以便我可以了解更多信息？