很多团队做埋点设计时，习惯把能想到的业务字段全部塞进事件属性。结果事件表越埋越臃肿，开发维护成本持续上升，真正要用的分析维度却凑不齐。反过来，也有人把属性定义得过于稀疏，到做漏斗分析、归因分析时才发现字段不够，只能返工补埋。
事件属性应该从分析场景反推，优先定义用户识别、业务对象、关键上下文三类信息，而不是无差别记录所有业务字段。这篇文章聚焦判断原则、分层方法、易混概念、行业示例和常见问题，不展开代码实现和工具选型。其中行业示例参考 ThinkingAI 在游戏、短剧、直播等业务的数据治理经验。
一、事件属性包括哪些：从分析场景反推三层
谈事件属性包括哪些，最实用的思路不是背字段清单，而是回到分析场景问三个问题：谁在这个行为里、动作作用在什么对象上、行为发生在什么环境。这三问对应事件属性的三个分层。
用户识别属性回答“谁在行为”。它把一次行为事件锚定到具体主体，典型字段包括用户ID、设备ID、账号类型、会员等级、来源渠道。没有用户识别属性，后续所有用户级分析都无法展开。
业务对象属性回答“动作作用在什么对象上、结果如何”。这是三层里最容易被低估的一层，典型字段包括商品/内容ID、类目、订单状态、支付方式、搜索关键词、优惠券ID。它决定了你能不能在事件流里还原业务过程，而不是只有一堆抽象的点击。
行为上下文属性回答“发生在哪、怎么触发”。典型字段包括页面/模块位置、入口来源、触发方式、应用版本、设备型号、网络环境。上下文属性通常不直接产生业务结论，但它是拆解行为差异、定位体验问题的基础。
需要强调的是，三层不是互斥关系。一个事件可以按需组合多个层次的属性，但要避免把长期稳定信息重复塞进每个事件。事件属性优先表达“这次行为特有的信息”，长期相对稳定的字段更适合放到用户属性或全局参数里，这一点在后面第三节会展开。
二、哪些业务信息该定义为事件属性：四个判断问题
面对一个业务字段不确定该不该定义为事件属性时，可以依次用四个问题过一遍。
1. 这个字段随事件变化还是随用户变化
随事件变化且属于本次行为结果的，优先定义为事件属性。当次搜索的关键词、当次点击的位置、当次购买的商品ID，都是典型的随事件变化字段。随用户变化且长期稳定的，更适合放进用户属性。用户的注册日期、会员等级、常驻城市，在一次行为中不会改变，放进事件属性只会造成冗余。
一个直观的判断：按钮点击位置属于事件属性，因为每次点击可能不同；用户累计付费档位更适合放用户属性，因为它描述用户主体而不是单次行为。
2. 后续分析是否要拿它做维度、筛选或分组
这是最核心的一道筛子。先问分析指标：如果未来不会按这个字段做分组、过滤或排序，就没有必要采集。订单状态、支付方式、内容ID、来源渠道之所以值得采，是因为它们直接参与漏斗、留存和归因分析。
反过来，按钮颜色、无业务含义的内部标识，除非后续确实会作为实验维度进入分析，否则不值得占用采集资源。这个判断标准能有效拦住大量拍脑袋加的字段。
3. 是否多个事件都会用到
高频被多个事件复用的字段，适合抽象为全局属性或公共属性，避免每个事件重复定义。来源渠道、应用版本、设备类型属于这一类，几乎每个行为事件都值得带上。
只服务于单个事件的字段，留在该事件内部即可，不要塞进公共属性污染全局。比如商品详情页点击时的商品ID，只有商品相关事件才需要，放进全局属性反而让其他事件多出无意义的空值。这节讨论的正是事件属性怎么设计和事件属性设计原则的核心问题。
4. 采集成本与数据稳定性是否可控
枚举值少、口径稳定、上报及时的字段优先采集。区实验分组标识、实验版本号这类字段只要实验期间稳定，就值得定义；取值混乱、变化快、跨团队理解不一致的字段应谨慎。临时调试用的字段更不宜进入正式埋点，否则后续清洗成本会持续累积。
实用做法是把候选字段分成“值得采”和“看看就好”两类。值得采的标准是：有明确分析用途、取值可控、口径统一。不满足其中任何一条的，先放着，等有真实分析需求再补。
三、事件属性和用户属性、全局参数怎么区分
1. 事件属性与用户属性的边界
事件属性跟着行为走，值随具体事件变化；用户属性描述用户主体，变化频率低。一次搜索的关键词是事件属性，因为它随每次搜索行为改变；用户的注册日期、常驻城市是用户属性，因为它们在较长时间内保持稳定。
判断标准可以简化成一句话：如果这个信息会因每次行为不同而不同，就优先放事件属性；如果长期相对稳定，就放用户属性。边界清晰后，埋点维护成本会明显下降。
2. 事件属性与全局参数的边界
全局参数是几乎所有事件都会携带的环境或渠道信息，如应用版本、联网方式、渠道来源。事件属性是特定事件才需要携带的信息，如商品详情页点击时的商品ID、下单时的订单金额。
两者的管理策略不同。全局参数应收敛、少而稳定，避免频繁增改；事件属性可随业务事件扩展，但要避免把全局参数当普通事件属性重复维护。一旦全局参数在每个事件里单独定义一遍，后续改动就是一场灾难。
3. 埋点行为数据与业务交易数据的边界
埋点行为数据记录“用户做了什么”，业务交易数据记录“业务结果是什么”，两者口径要区分。前端埋点无法准确拿到或历史状态复杂的信息，不宜硬塞进事件属性，可通过ID关联在数据侧补充。优惠券真实优惠金额、订单最终状态就是典型例子，这些字段以后端交易数据为准更可靠。
这样做能减少前端接口压力，也避免行为数据和交易数据口径互相打架。行为数据适合做过程分析，交易数据适合做结果确认，各司其职。
四、游戏、短剧、直播里的事件属性设计示例
1. 游戏场景
游戏埋点里值得定义的事件属性包括：关卡ID、道具ID、付费档位、战斗结果、活动ID。设计思路是用属性值区分不同关卡、不同战斗，而不是把“通关1-1”“通关1-2”拆成多个事件。
这样设计的直接收益是，关卡转化、道具消耗、付费节点这几类关键分析，都能用同一事件加属性完成。事件数量得到控制，分析模型也能稳定复用。
2. 短剧场景
短剧业务常见的事件属性包括：剧集ID、观看进度、付费点位置、来源渠道、卡片点击位置。用内容ID和进度表达用户观看行为，用来源渠道归因起量，用付费点判断转化卡点。
重点是避免把每一集、每一个推荐位都建成独立事件。属性值可以承载差异，事件数量保持收敛。ThinkingAI 在短剧类业务的数据治理实践里，这个思路被反复验证过。
3. 直播场景
直播间的事件属性典型字段包括：直播间ID、主播ID、互动类型、商品卡片ID、弹幕类型。设计思路是让点赞、评论、分享、商品点击等互动行为共用一个事件，用互动类型属性区分，降低事件数量。
互动活跃、商品转化、主播表现这几类分析目标，都能基于统一事件和属性完成，分析口径也更容易对齐。
4. 电商与新零售场景
电商和新零售业务值得定义的事件属性包括：商品ID、SKU、搜索关键词、优惠券ID、订单状态、支付方式。把商品、优惠券等业务对象做成属性，后端订单数据按ID关联，避免前端重复采集交易结果。
搜索转化、商品曝光到购买、优惠券核销这几条分析链路，都依赖稳定的业务对象属性。对象ID一旦缺失或不统一，整条转化分析就断了。
五、事件属性设计常见问题与避坑
1. 属性过多或过少
属性过多会造成埋点表臃肿、维护成本高；属性过少则后续分析维度不足，返工成本更高。两者都是真实的成本，只是发生的阶段不同。
对策是从核心指标反推，先列清楚“要算什么、需要什么维度”，再决定事件属性。优先覆盖关键转化链路，再按业务节奏逐步扩展，不追求一次埋全。
2. 命名与口径不一致
同一按钮在不同端分别叫ClickButton、btn_click、ButtonClick，后续清洗靠猜。同一个曝光指标，前端字段口径和数仓过滤条件不一致，容易产生数据事故。
对策是统一事件与属性命名规范，维护埋点字典，并把字段值域、统计口径写成文档。命名规范的价值不在文档本身，在于团队能持续按同一套规则协作。
3. 上报时机与重复上报
页面切后台再切回可能重复计算曝光，页面关闭时数据可能未上报，都会造成数据偏差。这类问题往往要到分析结果异常时才暴露，排查成本很高。
对策是明确曝光、点击、浏览等事件的触发时机和去重策略，必要时做客户端与后端对账。同时要避免高频事件因上报过于频繁影响接口性能，也避免页面退出导致关键事件丢失。
4. 行为口径与业务结果不一致
行为数据记录过程，业务交易数据记录结果，两者若不在同一口径下分析，会得出冲突结论。常见的场景是，前端点击支付按钮被当作支付成功统计，与后端实际支付结果对不上。
对策是区分埋点行为数据与交易数据边界，能用ID关联补充的字段不硬塞进前端事件属性。涉及订单、支付、退款等强业务结果，建议以后端交易数据为准，行为数据用于过程分析。
六、事件属性常见问题
事件属性包括哪些？通常包括用户识别、业务对象、行为上下文三类信息，按分析场景决定取用哪些字段。三类信息分别回答“谁在行为”“作用在什么对象上”“发生在什么环境”。
事件属性怎么设计？从分析指标反推，先确定要计算的指标和维度，再定义事件和属性，而不是先埋点后想怎么用。这个顺序能显著减少低价值字段的采集。
埋点事件属性有哪些？常见有用户ID、设备ID、来源渠道、商品/内容ID、订单状态、支付方式、搜索关键词、页面位置、应用版本等。具体取舍取决于业务分析目标，不必一次采全。
业务信息如何定义事件属性？判断该信息是否随事件变化、是否参与后续分析、是否多事件复用、采集成本是否可控，满足条件再定义为事件属性。四个条件是一个过滤框架，不是硬性门槛。
事件属性设计原则是什么？从分析场景反推、优先业务对象和关键上下文、避免过度采集、统一命名口径、保持从属关系清晰。原则的作用是把埋点从一次性动作变成可治理的长期资产。
