ക്ലയന്റ്-സൈഡ് ഇവന്റ് ട്രാക്കിങ്ങിനെ പൊതുവെ മൂന്ന് വിഭാഗങ്ങളാക്കാം:

  • കോഡ് അധിഷ്ഠിത ട്രാക്കിങ്
  • ദൃശ്യ ട്രാക്കിങ്
  • സ്വയമേവയുള്ള ട്രാക്കിങ്

ഈ ലേഖനം പ്രധാനമായും സ്വയമേവയുള്ള ട്രാക്കിങ്ങിന്റെ ആശയങ്ങളും നടപ്പാക്കൽ പ്രക്രിയയും പരിചയപ്പെടുത്തുന്നു.

1. കോഡ് അധിഷ്ഠിത ട്രാക്കിങ്

കോഡ് അധിഷ്ഠിത ട്രാക്കിങ് എന്നത് ട്രാക്ക് ചെയ്യേണ്ട ഓരോ പോയിന്റിലും ഒരു ഇന്റർഫേസ് വിളിച്ച് ഇവന്റ് ഡാറ്റ നേരിട്ട് അപ്‌ലോഡ് ചെയ്യുന്നതാണ്. ഭൂരിഭാഗം മൂന്നാം കക്ഷി അനലിറ്റിക്സ് സേവനങ്ങളും സൗകര്യപ്രദമായ കോഡ് അധിഷ്ഠിത ട്രാക്കിങ് api നൽകുന്നു.

എന്നാൽ ഇതൊരു പ്രശ്നമുണ്ടാക്കുന്നു: ട്രാക്കിങ് കോഡ് ബിസിനസ് ലോജിക്കിലുടനീളം ചിതറുകയും അതുമായി ശക്തമായി ബന്ധിക്കപ്പെടുകയും ചെയ്യുന്നു. സ്ക്രീനുകളോ ബിസിനസ് ഫ്ലോകളോ മാറുമ്പോൾ പഴയ ഇവന്റുകൾക്ക് എന്തുചെയ്യണം, പുതിയവ വേണമോ എന്നത് വ്യക്തമല്ല. ഇവന്റുകൾ കൂടുമ്പോൾ ചിതറിയ ട്രാക്കിങ് കോഡ് പരിപാലിക്കുന്നത് ദുഷ്കരമാകുന്നു. മാക്രോകളും ഫാക്ടറി ക്ലാസുകളും കോഡ് ലളിതമാക്കാം, എന്നാൽ അടിസ്ഥാന പ്രശ്നം മാറുന്നില്ല.

- (void)viewDidDisappear:(BOOL)animated {
    [super viewDidDisappear:animated];
    // 埋点
    APE(kEvent4001);
}

2. ദൃശ്യ ട്രാക്കിങ്

ദൃശ്യ ട്രാക്കിങ് ഒരു ദൃശ്യ ഉപകരണത്തിലൂടെ ശേഖരണ പോയിന്റുകൾ ക്രമീകരിക്കുന്നു. ക്ലയന്റ് കോൺഫിഗറേഷൻ സ്വയമേവ വായിച്ച് ഇവന്റുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു; ഇതിനെ “അടയാളമില്ലാത്ത ട്രാക്കിങ്” എന്ന് വിളിക്കുന്നു. പ്രതിനിധിയായ ഓപ്പൺ സോഴ്‌സ് പരിഹാരം Mixpanel ആണ്.

3. സ്വയമേവയുള്ള ട്രാക്കിങ്

ഫുൾ-ഇവന്റ് ട്രാക്കിങ് എന്നും വിളിക്കുന്ന സ്വയമേവയുള്ള ട്രാക്കിങ് യഥാർത്ഥത്തിൽ ഇൻസ്ട്രുമെന്റേഷൻ ഇല്ല എന്നർത്ഥമല്ല. അത് എല്ലാ ഇവന്റുകളും ശേഖരിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു; ഉപകാരപ്രദമായ ഡാറ്റ സെർവർ ഫിൽട്ടർ ചെയ്യുന്നു.

കൂടുതൽ മെച്ചപ്പെടുത്താൻ സെർവർ ഒരു കോൺഫിഗറേഷൻ ഫയൽ അയച്ച് ക്ലയന്റിൽ തന്നെ ഇവന്റുകൾ ഫിൽട്ടർ ചെയ്യാം.

KPIകൾക്കായി, ഈ ആശയം ചുറ്റി ചക്രം വീണ്ടും കണ്ടുപിടിച്ച് WKTrackingData നിർമ്മിച്ചു.

ഇവിടെ, WKTrackingData നടപ്പാക്കുമ്പോൾ നേരിട്ട ചില പ്രശ്നങ്ങളും ആശയങ്ങളും രേഖപ്പെടുത്തുന്നു.

നടപ്പാക്കൽ ആശയം ലളിതമാണ്. കോഡ് ഇങ്ങനെ ക്രമപ്പെടുത്തിയിരിക്കുന്നു:

യഥാർത്ഥ WKTrackingData ആർക്കിടെക്ചർ: മാനേജർ, ഇവന്റ് പാത്തുകൾ, AOP മൊഡ്യൂളുകൾ

ഇവിടെ WKTrackingDataManager എല്ലാ ഡാറ്റ മാനേജ്മെന്റും ഇവന്റ് ട്രാക്കിങ് കോൺഫിഗറേഷനും കൈകാര്യം ചെയ്യുന്നു.

ഇവന്റ് ട്രാക്കിങ് കോൺഫിഗറേഷന്റെ യഥാർത്ഥ ഉപയോഗ ഉദാഹരണം

WKTrackingDataViewPathHelper എന്നത് event_path മൂല്യങ്ങൾ സൃഷ്ടിക്കുന്നു.

AOP ഓരോ ഇവന്റും ട്രാക്ക് ചെയ്യുന്ന മൊഡ്യൂളാണ്.

വിശദമായ ഉപയോഗത്തിന് GitHub സന്ദർശിക്കുക.

ഒരു ഇവന്റിനെ എങ്ങനെ അതുല്യമായി തിരിച്ചറിയാം?

രണ്ട് ചോദ്യങ്ങളുണ്ട്: ഒരു ഇവന്റിനെ എങ്ങനെ പ്രതിനിധീകരിക്കും, അതിന്റെ അതുല്യത എങ്ങനെ ഉറപ്പാക്കും?

ഒരു ഇവന്റ് പ്രതിനിധീകരിക്കൽ

ഇവന്റുകളെ event_path ഉപയോഗിച്ച് പ്രതിനിധീകരിക്കുന്നു. ഇവന്റ് പ്രവർത്തിപ്പിക്കുന്ന responderന്റെ responder chain പിന്തുടർന്ന് അതിന്റെ path നിർമ്മിക്കുകയാണ് പ്രധാന ആശയം.

ലഭിക്കുന്ന responder path ഇങ്ങനെയാണ്:

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate
ഒരു ഇവന്റിനെ അതുല്യമായി തിരിച്ചറിയൽ

ചില ബിസിനസ് സാഹചര്യങ്ങളിൽ ഒരേ button അല്ലെങ്കിൽ മറ്റൊരു കൺട്രോളിന്റെ ഗുണങ്ങൾ മാറുമ്പോൾ അത് വ്യത്യസ്ത ബിസിനസ് ഇവന്റുകളെ പ്രതിനിധീകരിക്കും.

ഉദാഹരണത്തിന്, ഹോം സ്ക്രീനിലെ button സൈൻ ഔട്ട് ചെയ്തിരിക്കുമ്പോൾ സൈൻ ഇൻ ചെയ്യാൻ ടാപ്പ് ചെയ്യുക എന്നും സൈൻ ഇൻ ചെയ്തശേഷം തിരിച്ചറിയൽ പൂർത്തിയല്ലെങ്കിൽ തിരിച്ചറിയൽ സ്ഥിരീകരിക്കുക എന്നും കാണിച്ചേക്കാം.

അതേ buttonന്റെ view tree മാറിയിട്ടില്ല; അതിനാൽ നിർമ്മിക്കുന്ന responder path അതേപടി തുടരുന്നു.

സമാന സാഹചര്യങ്ങളിൽ UISwitchന്റെ on/off നില, UISegmentedControlന്റെ indexSelect ഗുണം, UIStepper, UITableView അല്ലെങ്കിൽ UICollectionViewയിലെ cell ഇടപെടലുകൾ ഉൾപ്പെടുന്നു.

ഇത് കൈകാര്യം ചെയ്യാൻ WKTrackingData കൺട്രോളിന്റെ ചില ഗുണങ്ങൾ തിരഞ്ഞെടുത്ത് ചേർത്ത് event_path നിർമ്മിക്കുന്നു. ഫലമായ event_path ഇങ്ങനെ:

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate#currentTitle=Button#state=1#enabled=1#selected=0";
ബിസിനസ്-നിർദ്ദിഷ്ട വിപുലീകരണങ്ങൾ

മറ്റൊരു സാഹചര്യം നോക്കാം: ഹോം സ്ക്രീനിലെ banner കാരസൽ.

ഓരോ banner സ്ഥാനത്തിന്റെയും ചിത്രവും ലക്ഷ്യ urlഉം സെർവർ നൽകുന്നു; സ്ഥാനങ്ങൾ ക്രമീകരിക്കാവുന്നതാണ്.

ഇവിടെ ഓരോ indexലെയും bannerന് സ്ഥിരമായ ലക്ഷ്യമില്ല. സ്ഥാനം 0യിലെ ഇവന്റ് event_path മാത്രം ഉപയോഗിച്ച് നിർണ്ണയിക്കാനാവില്ല.

ഇവന്റിനെ അതുല്യമായി തിരിച്ചറിയാൻ url പോലുള്ള ബിസിനസ്-നിർദ്ദിഷ്ട പാരാമീറ്റർ ചേർക്കണം.

WKTrackingData ബിസിനസ് പാരാമീറ്റർ വിപുലീകരണവും പിന്തുണയ്ക്കുന്നു; കോളർക്ക് കസ്റ്റം പാരാമീറ്ററുകൾ ചേർക്കാം:

ബിസിനസ് പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ഇവന്റുകൾ വിപുലീകരിക്കുന്ന യഥാർത്ഥ കോഡ് ഉദാഹരണം

ട്രാക്ക് ചെയ്യേണ്ടതില്ലാത്ത കൺട്രോളുകൾ wk_ignoreTracking ഉപയോഗിച്ച് ഒഴിവാക്കാം:

self.slider.wk_ignoreTracking = YES;

മറ്റു പ്രശ്നങ്ങൾ

വ്യത്യസ്ത ഇവന്റുകൾ ട്രാക്ക് ചെയ്യാൻ WKTrackingData aspect-oriented സമീപനം സ്വീകരിച്ച് runtime ഉപയോഗിച്ച് രീതികൾ നേരിട്ട് swizzle ചെയ്യുന്നു.

എന്നാൽ UIAlertView, UIActionSheet, UITableView, UICollectionView എന്നിവ ട്രാക്ക് ചെയ്യാൻ അവയുടെ delegate രീതികൾ swizzle ചെയ്യണം.

  • ഒരു delegate class ഇതിനകം രീതി നടപ്പാക്കിയിട്ടുണ്ടെങ്കിൽ അതിനെ നേരിട്ട് swizzle ചെയ്യുക.

  • ഒരു delegate class അത് നടപ്പാക്കിയിട്ടില്ലെങ്കിലും ഇവന്റ് ട്രാക്ക് ചെയ്യണമെങ്കിൽ ബന്ധപ്പെട്ട delegate methodന്റെ നടപ്പാക്കൽ കൈകൊണ്ട് ചേർക്കണം.

- (void)wk_swizzleInstanceSelector:(SEL)origSel_ fromClass:(Class)fromClass replaceSelector:(SEL)replaceSel_ originNotImp:(SEL)notImpSel_ {
    Method originalMethod = class_getInstanceMethod([self class], origSel_);
    if (originalMethod) {
        [self wk_swizzleInstanceSelector:origSel_ fromClass:fromClass replaceSelector:replaceSel_];
    } else {
        Method notImpMethod = class_getInstanceMethod(fromClass, notImpSel_);
        // 如果delegateClass没有实现 origSel_ 方法
        // 则给delegateClass的 origSel_ 添加 orginReplaceMethod 的实现
        BOOL didAddNotImpMethod =
        class_addMethod([self class],
                        origSel_,
                        method_getImplementation(notImpMethod),
                        method_getTypeEncoding(notImpMethod));
        if (didAddNotImpMethod) {
            NSLog(@"%@ did add not imp method %@" , NSStringFromClass([self class]) , NSStringFromSelector(notImpSel_));
        }
    }
}

നടപ്പാക്കൽ ഇവിടെ

എന്നാൽ പ്രായോഗികമായി UITableView, UICollectionView എന്നിവയുടെ delegate object രീതി നടപ്പാക്കാത്തപ്പോൾ, tableView:didSelectRowAtIndexPath:ന് കൈകൊണ്ട് implementation ചേർത്തിട്ടും അത് പ്രവർത്തിച്ചില്ല.

ആദ്യം സാധാരണ tableView:didSelectRowAtIndexPath: call stack നോക്കാം:

ടേബിൾ-വ്യൂ നിര തിരഞ്ഞെടുക്കലിന്റെ യഥാർത്ഥ ഡീബഗർ കോൾ സ്റ്റാക്ക്

ഇവിടെ ഒരു cell ടാപ്പിന് പ്രതികരിക്കാൻ UITableView ഈ നാല് രീതികളും ക്രമത്തിൽ വിളിക്കുന്നു:

  • 1. [UITableView _userSelectRowAtPendingSelectionIndexPath:]
  • 2. [UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:]
  • 3. [UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:]
  • 4. [TableViewController tableView:didSelectRowAtIndexPath:]

കോൾ ക്രമത്തിൽ നിന്ന് UITableView സ്വന്തം _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect: രീതി ആദ്യം വിളിച്ചശേഷം മാത്രമാണ് delegate classന്റെ tableView:didSelectRowAtIndexPath: വിളിക്കുന്നത് എന്ന് കാണാം.

ഈ _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:ൽ breakpoint വച്ച് assembly പരിശോധിക്കുക:

delegate-method ബ്രാഞ്ച് കാണിക്കുന്ന യഥാർത്ഥ assembly കാഴ്ച

ഒരു delegate class എന്നത് tableView:didSelectRowAtIndexPath: നടപ്പാക്കിയാൽ എല്ലാം പ്രവർത്തിച്ച് tableView:didSelectRowAtIndexPath: കോൾ പൂർത്തിയാകും.

എന്നാൽ delegate class എന്നത് tableView:didSelectRowAtIndexPath: നടപ്പാക്കിയിട്ടില്ലെങ്കിൽ, tableView:didSelectRowAtIndexPath:ന് കൈകൊണ്ട് implementation ചേർത്തിട്ടും tableView:didSelectRowAtIndexPath:ന് പ്രതികരിക്കാൻ ശ്രമിക്കില്ല.

assembly പിന്തുടർന്നാൽ നേരിട്ട് മറ്റൊരു നിർദ്ദേശത്തിലേക്ക് jump ചെയ്യുന്നു.

WKTrackingData ഇവിടെ മറ്റൊരു സമീപനം സ്വീകരിക്കുന്നു: [UITableView _userSelectRowAtPendingSelectionIndexPath:] നേരിട്ട് swizzle ചെയ്യുന്നു (UICollectionViewനും സമാന സമീപനം). delegate object ബന്ധപ്പെട്ട cell event രീതി നടപ്പാക്കിയിട്ടില്ലെങ്കിലും UITableView, UICollectionView ഇടപെടലുകൾ ട്രാക്ക് ചെയ്യാൻ ഇതിലൂടെ കഴിയും.

4. അവസാന ചിന്തകൾ

ഒരേ ഇവന്റിന് പല event_path മൂല്യങ്ങൾ

സ്ക്രീനുകളിൽ ചെറിയ വ്യത്യാസങ്ങളുള്ള പല റിലീസ് പതിപ്പുകൾ പരിഗണിക്കുക. ഒരേ ഇവന്റിന് അപ്പോൾ പല event_path മൂല്യങ്ങൾ ഉണ്ടായേക്കാം.

പ്രായോഗികമായി ഈ മാപ്പിങ്ങിന് സെർവർ-സൈഡ് സഹപ്രവർത്തകരുടെ സഹകരണം വേണം. ബാക്ക്‌എൻഡിൽ ക്രമീകരിക്കാവുന്നതാക്കാം.

ഇവന്റ് അനലിറ്റിക്സ് മെച്ചപ്പെടുത്തൽ

ഈ ബിസിനസ്-നിർദ്ദിഷ്ട വിപുലീകരണങ്ങൾ വിഭാഗം ബിസിനസ് പാരാമീറ്ററുകൾ ചേർക്കുന്നത് വിവരിച്ചു. WKTrackingData ഇത് categories ഉപയോഗിച്ച് നടപ്പാക്കുന്നു.

പ്രായോഗികമായി ഫുൾ-ഇവന്റ് ട്രാക്കിങ് ഏറെ bandwidth പാഴാക്കി. പല ഇവന്റുകളും ആവശ്യമില്ലായിരുന്നു [(ŏ_ŏ)].

കൂടുതൽ മെച്ചപ്പെടുത്തലായി റിപ്പോർട്ട് ചെയ്യേണ്ട എല്ലാ ഇവന്റുകളും പട്ടികപ്പെടുത്തിയ കോൺഫിഗറേഷൻ ഫയൽ സെർവർ അയയ്ക്കാം. കോൺഫിഗറേഷനുമായി പൊരുത്തപ്പെടുന്ന event_path മാത്രം അപ്‌ലോഡ് ചെയ്യും.

ഈ ഘട്ടത്തിൽ WKTrackingData ഇല്ലാതെയും ബിസിനസ് പാരാമീറ്ററുകൾ നേടാം: നേരിട്ട് kvc ഉപയോഗിക്കുക.

ഉദാഹരണത്തിന്:

key_path = "viewController.banner.url"

ഇത്രയും വായിച്ചെങ്കിൽ WKTrackingData തുറന്ന് ഒരു star നൽകൂ. ചോദ്യങ്ങളുണ്ടെങ്കിൽ GitHub-ൽ issue തുറക്കുകയോ താഴെ കമന്റ് ചെയ്യുകയോ ചെയ്യൂ!