總體流程

神策分析提供了非常完備的數據接入方案，無論您的產品採用哪種技術架構，都可以非常容易的接入神策系統。

一般情況下，進行一次完整數據接入的流程如下：

  1. 理解神策分析的基本概念，了解神策是做什麼的，尤其是需要重點閱讀 數據模型 的說明。
  2. 如果有對應的神策數據分析師協助，請確認已經拿到對應的數據採集方案，其中應當包含了所有的事件及屬性的設計建議。
  3. 如果是使用私有部署的方案，請和相關維運同事確認已經設定好正確的數據接入網址。如果對這一點不確定，請聯繫神策技術支援。
  4. 測試數據和正式數據應該接入到不同的專案中，具體概念請參考 多專案。
  5. 根據數據採集方案和相關需求，按需要進行具體的接入工作，例如在用戶端實施埋點或者匯入歷史數據，詳情參考第二節。
  6. 進行數據測試和驗證，完成驗證之後再上線到正式的環境。  

以上流程僅供參考，如有任何疑問請聯繫您的神策諮詢顧問。

接入步驟

要點說明

  1. 無論使用哪種接入方式，建議先閱讀 數據格式，更好的理解神策數據接入的原理。
  2. 建議開發的時候使用 除錯模式 測試數據採集的正確性和追查問題。 注意：Debug 模式是為方便開發者除錯而設定的模式，該模式會逐條校驗數據並在校驗失敗時拋出異常，性能遠低於正常模式。線上環境使用 Debug 模式會嚴重影響性能並存在崩潰風險，產品上線前請務必替換掉/關閉 Debug 模式。
  3. 經常使用 埋點管理 查看接入的詳細情況。
  4. 嚴格按照數據採集方案的定義來進行埋點，尤其注意不同來源（例如安卓/iOS，或者歷史數據等）的事件、屬性需要統一考慮，以免出現定義的衝突，尤其是數據型別的定義。例如以下是一些典型的錯誤用法：
    1. Android 支付事件叫 pay_order，iOS 的支付事件叫 PayOrder，這樣會造成使用和理解上的困難。
    2. Android 端的金額屬性叫 money，型別是數字，而 iOS 端使用的是字串型別，會導致數據無法匯入。
  5. 一個屬性的型別由首次匯入時的型別決定，後續匯入只接受相同型別的輸入， 型別不一致的輸入數據會被整條拒絕。
  6. 事件名稱、屬性名稱、屬性型別在一般情況下是不能修改的，請務必確認事件屬性設計之後再進行數據接入。如果是測試階段中有事件、屬性的變更，可以使用專案重置功能來重新初始化測試環境：多專案管理工具使用說明。 

如何標識用戶

所謂標識用戶，是指選擇一個合適的標識符（例如裝置 ID 或者註冊 ID）作為 distinct_id 來發送數據到神策。是否選擇了合適的 distinct_id 對數據分析的準確性會有很大影響，因此，在進行任何數據接入之前，都應當先確認您的用戶標識方式。神策分析提供了靈活、強大的用戶標識能力，您可以根據自己的需求來選擇合適的方案，具體請閱讀文件 標識用戶。如果您依然不確定如何進行用戶標識，請聯繫神策的數據分析師。

用戶端埋點

如果您不需要從用戶端接入數據，可以跳過此段。

用戶端接入目前有以下幾類方案：

  1. 直接使用神策用戶端 SDK（.用戶端 SDK v1.13）。這個方案相對簡單、易用，並且神策 SDK 提供了更多內建的功能（例如 渠道追蹤 等）和可靠性保證（例如網絡不好的情況下延遲發送）。同時神策的所有 SDK 都是完全開源的，不用擔心有後門之類的安全問題。一般情況下，我們建議採用此方案。
  2. 使用已有的業務 API，把埋點需要的數據同步傳到業務伺服器，然後在伺服器端再使用神策的伺服器端 SDK（Java SDK） 進行接入。這個方案本質上其實是伺服器端埋點，優點是對於業務統計可能會更加準確（因為和業務呼叫是同步的），安全性比較高（可以進行一定的用戶端加密來增大偽造數據的難度），缺點是實施難度較大。我們一般建議對於關鍵的業務事件（例如購買、支付等）採用這種方案。
  3. 使用自己的埋點 SDK。如果您已經使用了自己的埋點 SDK，並且已經比較完善了，那麼可以繼續使用此方案，然後和方案 2 一樣透過伺服器端接入。
  4. 如果您使用的是神策暫時不支援的用戶端（例如 PC / Mac 軟體），那麼可以使用方案 2 或者方案 3，當然 也可以在用戶端直接使用神策的 數據接入 API 進行接入。

伺服器端埋點

如果您不需要從伺服器端接入數據，可以跳過此段。

不管是用戶端的埋點數據透過 API 發送給伺服器端之後，還是直接在伺服器端的已有業務邏輯裡直接埋點，都屬於伺服器端接入。伺服器端接入可以使用 伺服器端 SDK 等 SDK，每個 SDK 均有不同類型的發送方案（即 Consumer）可以選擇，有兩大類方案：

  1. 使用直接發送數據的 Consumer（例如 Java 的 AsyncBatchConsumer），即時的發數據給神策的服務。優點是方便簡單，缺點是在機器故障或者超大流量的極端情況下可能會丟失一小部分數據，並且可能對業務造成一定影響。如果數據量不大可以使用此方案。
  2. 使用寫入本地日誌的 Consumer（例如 Java 的 LoggingConsumer），配合 LogAgent 進行匯入。優點是因為有本地持久化，可靠性會更高，缺點是程式碼會稍微複雜，同時還需要自己負責本地日誌的儲存和刪除等維運操作。建議在大數據量或者對數據準確性有高要求的時候使用此方案。

在一般情況下，我們都建議在服務的入口處（例如 MVC 的 Controller 層）進行埋點，這樣既能獲取到大部分埋點所需要的數據，又方便統一管理：如果有埋點額外需要的用戶端數據（例如裝置資訊），可以透過 API 參數傳入；對於埋點需要的業務數據（例如下單事件的優惠資訊），則可以透過業務處理模組回傳給 Controller 層。

工具匯入（歷史數據匯入）

如果您沒有歷史數據需要接入，可以跳過此段。

對於已經存在的歷史數據，無論是事件還是用戶屬性，我們都建議使用 Java SDK／PHP SDK SDK 產生特定格式的數據，然後使用 LogAgent（SaaS 版）、BatchImporter小數據量/私有部署） 或者HdfsImporter（大數據量/私有部署/叢集版）等工具進行匯入。也可以不使用 SDK，直接按照數據格式裡的說明產生數據並匯入。

一般情況下，歷史數據即可以先匯入，也可以等即時數據正式接入之後再匯入，不影響最終的分析結果。但是如果使用了login / track_signup，則請務必閱這裡的 標識用戶，避免匯入數據順序不對導致的用戶 ID 關聯錯誤。

用戶屬性的接入

用戶屬性（Profile）是可選的，如果您的業務裡並不需要接入用戶屬性，可以跳過此段。

事件（Event）總是在事件發生的時候進行 track，而用戶屬性（Profile）則不是那麼固定，而是根據不同屬性會有所不同，主要還是取決於具體屬性的取得方式，一般來說主要有以下幾種方式：

  1. 伴隨事件的發生：例如神策提供的用戶端 SDK 會預設在用戶首次訪問的時候，設定用戶的 首次訪問時間 等屬性。類似的，您也可以主動在用戶首次購買的時候呼叫 profile_set_once 設定一個 首次購買時間 的屬性。
  2. 在屬性修改時接入：即在某個用戶屬性被修改的時候（例如修改用戶資料的介面）同時呼叫 profile_set 系列介面。
  3. 定時同步匯入：即定時從業務數據庫或者其它數據源中導出數據，然後用 LogAgent／BatchImporter 匯入神策系統。這裡應該儘量用最後更新時間之類的欄位來實現增量匯入，否則每次全量匯入可能會影響性能。
  4. 即時同步匯入：例如 MySQL 可以使用 Applier 來對數據的 Binlog 進行即時解析和同步，其它數據庫也可以使用類似的工具。此方案的優點是不用修改已有業務程式碼，耦合性較低，但是需要根據具體數據庫類型進行額外的開發。 

由於用戶屬性的匯入效率會低於事件，因此應該儘量避免非必要的 profile 操作，例如在數據沒有變化的情況下重複更新某一個 profile。