事件是驱动deltaDNA分析的基本结构。
事件代表了游戏中的行为，其提供了玩家在该点状态的一个快照，并给出历史中一个这时可以用于创建一个玩家行为的点。描述你的游戏中一个特殊点玩家行为和状态的事件被以小的JSON文件发送到deltaDNA。
立刻获得事件列表是至关重要的，其他一切事情都是基于提供适当层次细节的稳健的事件。
与其他的分析提供商不同，deltaDNA对于事件和事件管理提供了略微不同的方法。
创建一个事件列表的关键步骤是：
- 运行/分析游戏
- 创建事件列表
- 退出事件列表
- QA事件列表
复杂事件
deltaDNA支持使用简单结构包含尽量多的行为信息的复杂事件。这意味着一个成绩事件将提供关于这个成绩自身的信息，以及玩家从这个成绩中获得的奖励。每个事件都可以包含这个游戏认为有用的尽量多的参数以充分描述行为。
这非常有用，因为所有的信息被保存在一起，使得下一步分析进行的更容易，从而你能够更容易的看到行为的结果。
这不会阻止你创建更简单的事件，你可以创建一个基于键/值事件的主导的事件结构，但是这不会使用deltaDNA系统的全部功能。
预定义事件
有50个预配置的事件覆盖了游戏中80%的使用案例。我们对每个添加的游戏自动监测这些事件的子集，因此你可以立刻开始发送数据。其他预定义事件是使其更容易的为你的游戏快速构建事件列表。每个预定义事件都可以使用游戏的特殊参数进行定制，而且你还可以创建你自己的自定义事件。
何时是一个有意义的事件
目的是收集有意义的事件。事件是游戏中被定义的某些事情发生的点，其应当代表一个玩家发起行为的时间点。
事件不是游戏发起的行为，其应当总是由玩家发起。有意义的含义很难被定义，其应当是一个对于游戏过程有实质性改变的行为，从而得到玩家响应。打一枪不是一个显著的事件，但杀死某人则会是。
定义有意义的点只能在游戏背景中进行，因此在一个狙击游戏中射击可能被定义为有意义，这时玩家只会进行很少几次射击，使用非常有限的弹药供给，每次射击对于玩家都有非常大的影响。
事件验证
发送到deltaDNA的每个事件在其允许被保存到数据库前需要根据事件列表进行验证。每个事件都有一系列被定义的标准，你可以通过添加额外的几个级别以使验证符合你想要的严格程度。
这种方法的优点是其阻止了坏数据进入数据库并影响全部分析。驱动决策做出良好分析的最大问题是数据较差或者未完成，数据验证则意味着数据库可以尽可能的的干净和完整。
环境
当一个新游戏被创建时，其总是会使用两个环境（开发DEV和实际LIVE）创建。
每个环境都独立运行，在这两个环境之间一整套的显示面板和数据都保持完全分离。这允许游戏针对开发（DEV）环境进行开发和测试，然后使用实际（LIVE）环境发布。更改后续版本的事件可以继续在开发（DEV）环境进行测试，而不会影响实际（LIVE）环境及创建错误数据。
事件只能在开发（DEV）环境被创建和编辑，然后必须发布到实际（LIVE）环境。一旦一个事件被推送到实际（LIVE）环境其将永远不能再实际（LIVE）环境中被删除。事件可以被分别发布，或者多个事件可以同时被发布。
发送事件
事件可以从客户端或服务器发送。多数的Facebook和网页游戏被称为“轻量级客户端”游戏。这意味着主要的游戏逻辑在服务器上，只有少量的代码在客户端运行视觉效果。deltaDNA REST API可以被用于从“轻量级客户端”游戏发送事件。
相对的被称为“重量级客户端”游戏。这些游戏主要的进程在客户端完成，只是用一个非常小的服务器管理玩家交互和虚拟商店。所有的移动设备游戏都是这样构建的，因为其无法依赖于持续的服务器连接，所以需要将在客户端保持进程。deltaDNA SDK应当被应用于移动设备，因为其可以管理本地的事件缓存以减轻间歇性的网络连接。然而，REST API也可以被应用于“重量级客户端”游戏，但是你将需要使用你自己开发的代码管理本地的事件缓存。deltaDNA SDK是使用REST API发送事件数据的轻量级封装。
服务器事件
如果事件来自于服务器，我们将从一个单一的连续位置获取它们。丢失数据的可能性要小得多。事件在其一被触发时就会被发送，事件将不会有任何延迟。
事件在deltaDNA服务器有时间戳标记，因此都将有与客户端时间无关的一致时间。这需要在分析时被考虑，因此时间将被使用协调世界时（UTC）标记，而不关心玩家在哪里玩这个游戏。
如果你从一个服务器发送事件，那么你的游戏详情页面中地理位置选项应被禁用，因为其将错误的设置玩家的位置为你的服务器位置。
一些事件不是游戏操作数据的一部分，因此不属于一个会话。通常这些是由除了玩家操作游戏之外的其他事情触发的服务器事件。因此如果发送一个事件将会使其看起来是玩家在这个时间点操作了游戏从而导致不便。如果你想要发送这样一个事件那么你可以省略会话ID和事件时间戳，我们这时将为玩家把这个事件补回到上一会话的结尾。例如，这对于归因数据或者为老用户填充新获取的数据将会非常有用。
批量服务器事件
这是服务器保持事件并按照有规律的时间一起发送它们。事件在服务器被标记时间，但是这意味着在我们看到事件前会有从几分钟到几小时的延迟。
客户端事件
所有的移动设备游戏和不断增长的电脑游戏在从客户端发送事件。从客户端发送的事件将会发送自大量设备，这极大的增加了事件丢失的可能性。
由于客户端缺少关于其他玩家的信息，一些信息更难以计算。任何需要关于不仅仅是当前玩家信息的事情将会非常困难，如果数据是从客户端而不是服务器发送，邀请和安装一个Facebook游戏是更复杂的。
虽然用户只能看到从其自己的客户端发送的数据，其可能导致deltaDNA服务器拒绝服务攻击变得更受关注；但是还有非常高的可能性数据会被攻击。
混合客户端/服务器事件
一些游戏使用混合模型，一些事件来自服务器，另外一些来自客户端。这通常是因为客户端很简单无法提供要求的信息，或者客户端的信息不一定是可信的。这通常会发生在从服务器发送的交易事件或者从网页服务器发送用户注册但是从客户端发送游戏行为事件。
在这些情况下，请小心处理你的用户ID、会话ID以及时间戳使用，并禁用自动的地理位置功能以防止服务器地址覆盖掉玩家的地址。
移动设备客户端事件
最复杂的事件类型是那些发送自移动设备客户端的事件。这是因为不仅其设备是“重量型”的，而且其还总是未连接的。这些游戏通常不依赖于连接性，且玩家可以在离线情况下愉快的玩游戏。
数据仍然使用deltaDNA SDK收集，并存储在设备本地。在某个周期性的点，游戏将尝试上传数据到deltaDNA服务器。如果这因为没有连接或者deltaDNA服务器的问题无法上传，数据将会保持在客户端。
这意味着数据将经常出现过晚，这可能是晚几分钟到几周的事情。因为数据在本地存储，每个事件都由设备添加时间戳标记。这意味着数据收集将有一个本地的时间戳而不是服务器的时间戳，每个其他的设备都是这样。
这还意味着我们依赖于设备有正确的时间，但我们发现少量设备设置的时间在过去或者未来。由于设备没有实时连接，我们可能从过去获取事件；考虑时区后，我们还可能获得未来的时间戳，这时我们要考虑是否删除这个事件。
任何早于过去一个月前或者晚于未来一天后的事件将会被收集服务器拒绝。
