iOS開發基礎142-廣告歸因

Mr.陳發表於2024-07-25
iOS

IDFA

IDFA是蘋果為iOS裝置提供的一個唯一識別符號，專門用於廣告跟蹤和相關的營銷用途。與之對應的，在Android平臺的是谷歌廣告ID（Google Advertising ID）。

IDFA的工作原理：

IDFA是分配給每個裝置的唯一識別符號，廣告商和開發者可以利用IDFA跟蹤使用者對廣告的點選情況，評估廣告效率等。從iOS 10開始，使用者可以選擇重置自己的IDFA或完全限制廣告追蹤，這提高了使用者的隱私保護。

當使用者同意跟蹤時，開發者可以透過特定的API獲取IDFA來實現針對使用者的廣告投放。如果使用者拒絕跟蹤，獲取到的IDFA將是一個全零的值。

如何在Objective-C中獲取IDFA：

  1. 首先，引入所需的框架：在你的iOS專案中，你需要引入AdSupport.framework。可以在Xcode中的專案設定裡，在“Build Phases” -> “Link Binary with Libraries”中新增這個框架。

  2. 新增App Tracking Transparency (ATT) 許可權請求：在Info.plist中新增NSUserTrackingUsageDescription鍵，其值為一個字串，用來在請求跟蹤許可權時，向使用者解釋為什麼應用需要此許可權。

  3. 請求許可權並獲取IDFA：在你的應用中，你需要根據使用者的授權狀態來獲取IDFA。以下是Objective-C的程式碼示例：

#import <AdSupport/AdSupport.h>
#import <AppTrackingTransparency/AppTrackingTransparency.h>

- (void)requestIDFA {
    if (@available(iOS 14, *)) {
        [ATTrackingManager requestTrackingAuthorizationWithCompletionHandler:^(ATTrackingManagerAuthorizationStatus status) {
            // 檢查使用者的授權狀態
            if (status == ATTrackingManagerAuthorizationStatusAuthorized) {
                // 使用者授權訪問IDFA
                NSString *idfaString = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
                NSLog(@"IDFA: %@", idfaString);
            } else {
                // 處理未授權狀態
                NSLog(@"使用者未授權訪問IDFA");
            }
        }];
    } else {
        // 針對iOS 14以下版本，直接獲取IDFA（這裡並未考慮使用者是否限制了廣告追蹤）
        if ([[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled]) {
            NSString *idfaString = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
            NSLog(@"IDFA: %@", idfaString);
        } else {
            NSLog(@"廣告追蹤受限");
        }
    }
}

在實際使用時，應當考慮到使用者的隱私，只在確實需要時請求許可權，並透明地告知使用者資料使用的目的。

原理：

從原理來說，IDFA是由蘋果作業系統生成並管理的。從開發者的角度來講，系統提供的APIASIdentifierManager的advertisingIdentifier方法用來訪問這個識別符號。系統會維護這個唯一識別符號的生成、更新（當使用者選擇重置IDFA時）以及使用者隱私設定的狀態（是否允許廣告跟蹤）。

蘋果對如何具體生成IDFA的細節並沒有公開過多的資訊，不過可以確定的是，它是為了保護使用者隱私而設計的，確保其用在廣告追蹤上的目的不會侵犯使用者的隱私權益。

注意：由於蘋果的隱私政策和技術實現會更新，獲取和使用IDFA的具體細節也可能隨之變化，開發者應當關注蘋果官方的最新文件。

如何區分當前下載的app是由哪個廣告帶來的?

在iOS平臺上，區分當前下載的App是由哪個廣告帶來的，主要依靠Apple的廣告歸因平臺——Apple Search Ads和第三方歸因平臺（如Adjust、Appsflyer、Branch等）。這些服務透過特定的技術手段，幫助開發者跟蹤和分析其廣告帶來的App安裝情況。下面我會分別介紹這兩類方案的基本做法。

1. Apple Search Ads

Apple Search Ads是Apple自家的廣告平臺，允許開發者在App Store內部推廣其應用。若要追蹤使用者是否透過Apple Search Ads廣告下載了你的App，你可使用Apple提供的搜尋廣告歸因（Search Ads Attribution）API。

步驟如下：

  • 首先，需要在你的應用程式中整合搜尋廣告歸因API。這可以透過在你的App中新增Apple的iAd框架，並呼叫歸因API來完成。

  • 當使用者透過Apple Search Ads點選廣告並下載App時，系統會記錄這次點選事件。

  • 透過呼叫歸因API，你的App可以訪問這次點選事件的歸因資訊。這些資訊包括廣告相關的後設資料，如廣告系列ID、關鍵詞ID等，從而讓你知道使用者是透過哪個廣告下載的App。

2. 第三方歸因平臺

除了使用Apple Search Ads之外，開發者還經常使用第三方歸因服務來追蹤和分析廣告活動的效果。這些第三方平臺能提供更為全面的歸因解決方案，包括多渠道歸因、廣告效果分析、ROI追蹤等功能。

實現方式大致如下：

  • 首先，你需要在你的App中整合所選第三方歸因服務商提供的SDK。

  • 當使用者點選了一個廣告並被引導到App Store下載你的App時，這個第三方平臺透過特定的追蹤連結記錄下這次事件。

  • 使用者安裝並首次開啟App時，整合的SDK會與第三方服務的伺服器通訊，傳遞相關的安裝事件資訊。

  • 第三方服務會根據提供的資料，分析並確認這次安裝是由哪個廣告或廣告系列帶來的，然後將這些資訊反饋給開發者。

需要注意的是：

  • 對於使用Apple Search Ads的情況，可以直接使用Apple提供的方案進行歸因。

  • 若需要跨平臺和跨廣告渠道進行歸因分析，第三方歸因平臺是一個更加靈活和全面的選擇。

  • 由於iOS 14及之後版本對使用者隱私和資料跟蹤提出了新的要求，使用歸因服務時需要遵守Apple的App Tracking Transparency (ATT)框架，向使用者請求並獲取跟蹤授權。

第三方歸因平臺

進一步的探究關於第三方歸因平臺的工作原理

第三方歸因平臺的基本概念

第三方歸因平臺，也就是移動應用歸因或廣告歸因服務，是專門設計來跟蹤、衡量和最佳化數字廣告活動效果的服務。它們可以精確地告訴開發者，哪些廣告、營銷渠道、或者是推廣活動帶來了實際的應用安裝、使用者行為甚至是收入。

工作原理

  1. 追蹤連結: 開發者在不同的廣告渠道上釋出廣告時，會使用歸因平臺生成的獨特追蹤連結。每個連結都包含了識別資訊，諸如廣告聯盟、廣告系列名稱、創意ID等。

  2. 點選事件: 當使用者點選了這個追蹤連結，歸因平臺會記錄這次點選事件，並生成一個唯一的識別符號（點選ID或者其他形式的標記）。然後使用者被引導至應用商店。

  3. 安裝與首次啟動: 使用者下載並首次啟動應用時，應用內整合的歸因平臺SDK會傳送一個與安裝相關的訊號給歸因服務，其中也包含了該裝置的獨特標識。

  4. 歸因匹配: 服務平臺透過一系列的匹配技術（如點選時間戳、裝置標識等）將之前記錄的點選事件與實際的應用安裝事件相匹配。

  5. 彙報與分析: 一旦成功匹配，平臺就能夠確定哪個廣告點選導致了安裝，進而生成詳盡的歸因報告，這些報告會為開發者提供廣告表現資料，如安裝量、使用者活躍度、ROI等關鍵指標。

挑戰及應對

  • 使用者隱私: 特別是在iOS 14以及更高版本中，蘋果推出的App Tracking Transparency (ATT)框架要求應用在追蹤使用者或訪問裝置廣告識別符號(IDFA)前獲取使用者許可。歸因平臺應對這一挑戰，部分是透過利用蘋果的SKAdNetwork等隱私友好的歸因解決方案來實現歸因，雖然這會犧牲一些資料精度和深度。

  • 歸因精度: 各個平臺和技術手段的不同可能會影響歸因的精度。歸因平臺不斷改進他們的演算法和技術（如抗欺詐技術），以確保資料的準確性。

結論

第三方歸因平臺提供了一個關鍵的服務，幫助移動應用開發者深入理解和最佳化他們的廣告投資回報率。透過專業的歸因技術和資料分析，開發者可以更明智地決策他們的廣告策略，提升使用者獲取效率，最大化廣告收益。然而，隨著使用者隱私保護的要求日益嚴格，這些平臺也在不斷適應新的規則，尋找平衡點。

問題？

如果我的app內整合兩個第三方的SDK，那麼是不是會出現兩家第三方都認為是自己帶來的下載？這樣的擔憂是有道理的。當App內整合了多個第三方歸因平臺的SDK時，理論上確實存在一個風險，即兩個（或更多）第三方平臺可能都會嘗試對同一個安裝事件進行歸因，而且都可能認為是由它們各自的追蹤連結引起的。這種情況，如果不加以妥善處理，確實可能導致歸因重疊或衝突，這會混淆實際廣告效果的認定。

如何解決歸因衝突？

  1. 使用單一歸因平臺：在實踐中，為避免歸因衝突，應用開發者和廣告主往往會選擇並堅持使用單一的歸因提供商。這樣做的好處是統一了歸因標準和方法，從而避免了資料的冗餘和衝突。

  2. 歸因深度連結技術：歸因平臺常用深度連結技術來精確追蹤使用者行為路徑，確保從點選到安裝的過程準確歸因。透過深度連結生成的唯一URL，即使有多個歸因SDK，也可以更準確地匹配到正確的點選事件和安裝。

  3. 歸因平臺協調：在一些複雜的營銷場景中，如果必須同時使用多個歸因平臺，那麼這些平臺之間通常需要有一定的協調機制，比如使用第三方中立資料管理平臺（DMP）來整合和協調不同來源的資料。這樣，即使有多個來源，也能準確判斷哪一個操作實際導致了安裝。

  4. 優先順序和最後點選歸因法則：在多個歸因平臺同時執行的場景中，通常有一套公認的優先順序規則或者遵守最後點選歸因（Last-Click Attribution）的原則。這意味著，儘管使用者可能接觸了多個推廣渠道的廣告，但最終歸因會規定給使用者最後點選的那個廣告來源。

結論

雖然理論上存在這樣的問題，但透過上述方法和策略的實施，大多數情況下都能有效避免歸因上的重疊或衝突。最佳實踐是，為了保證資料的準確性和可操作性，選擇一個信任度高、技術支援強的歸因平臺作為唯一的歸因夥伴。這不僅能保證資料的一致性，還能避免多頭管理帶來的複雜性與成本增加。同時，歸因平臺本身也在不斷最佳化他們的演算法和技術，以提高歸因的準確性和效率。

相關文章