iOS-இல் தானியங்கு நிகழ்வு கண்காணிப்பு

Client-side நிகழ்வுக் கண்காணிப்பு பொதுவாக மூன்று வகைகளாகப் பிரிகிறது:

• குறியீடு அடிப்படையிலான கண்காணிப்பு
• காட்சிவழிக் கண்காணிப்பு
• தானியங்குக் கண்காணிப்பு

இந்தக் கட்டுரை முக்கியமாக தானியங்குக் கண்காணிப்பின் யோசனைகளையும் செயலாக்கப் பயணத்தையும் அறிமுகப்படுத்துகிறது.

1. குறியீடு அடிப்படையிலான கண்காணிப்பு

குறியீடு அடிப்படையிலான கண்காணிப்பு என்பது கண்காணிக்க வேண்டிய ஒவ்வொரு இடத்திலும் ஓர் interface-ஐ அழைத்து, நிகழ்வுத் தரவை நேரடியாகப் பதிவேற்றுவதாகும். பெரும்பாலான மூன்றாம் தரப்பு analytics சேவைகள் இதற்கான api-ஐ வழங்குகின்றன; அது வசதியானது.

ஆனால் இதில் ஒரு சிக்கல்: கண்காணிப்புக் குறியீடு business logic முழுவதும் சிதறி, அதனுடன் இறுக்கமாக இணைகிறது. திரைகளோ business flows-ஓ மாறும்போது பழைய நிகழ்வுகளை என்ன செய்வது, புதியவை தேவையா என்பது தெளிவாக இருக்காது. நிகழ்வுகளின் எண்ணிக்கை உயர்ந்ததும் சிதறிய குறியீட்டை பராமரிப்பது பெரும் சிரமமாகும். Macros மற்றும் factory classes குறியீட்டை எளிதாக்கலாம்; ஆனால் அடிப்படையில் எதையும் மாற்றாது.

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

2. காட்சிவழிக் கண்காணிப்பு

காட்சிவழிக் கண்காணிப்பு, காட்சிக் கருவின் மூலம் சேகரிப்புப் புள்ளிகளை அமைக்கிறது. Client அந்த அமைப்பைத் தானாகப் புரிந்து நிகழ்வுகளை அனுப்பி, “சுவடில்லா கண்காணிப்பு” எனப்படுவதை உருவாக்குகிறது. குறிப்பிடத்தக்க open-source தீர்வுகளில் ஒன்று Mixpanel.

3. தானியங்குக் கண்காணிப்பு

Full-event tracking என்றும் அழைக்கப்படும் தானியங்குக் கண்காணிப்பு, கருவியமைப்பே தேவையில்லை என்று உண்மையில் பொருளல்ல. அது எல்லா நிகழ்வுகளையும் சேகரித்து அனுப்புகிறது; பயனுள்ள தரவை server வடிகட்டுகிறது.

மேலும் மேம்படுத்த, client தானாக நிகழ்வுகளை வடிகட்டும்படி server ஓர் configuration file-ஐ அனுப்பலாம்.

KPI-களுக்காக, இந்த யோசனையைச் சுற்றி சக்கரத்தை மறுபடியும் கண்டுபிடித்து WKTrackingData-ஐ உருவாக்கினேன்.

இங்கே WKTrackingData செயலாக்கத்தில் சந்தித்த சில சிக்கல்களையும் யோசனைகளையும் பதிவு செய்கிறேன்.

செயலாக்க யோசனை எளிது. குறியீடு பின்வருமாறு அமைக்கப்பட்டுள்ளது:

இங்கே WKTrackingDataManager அனைத்து தரவு மேலாண்மையையும் நிகழ்வுக் கண்காணிப்பு அமைப்பையும் கையாளுகிறது.

WKTrackingDataViewPathHelper என்பதன் பணி event_path மதிப்புகளை உருவாக்குவது.

ஒவ்வொரு நிகழ்வையும் கண்காணிக்கும் பொறுப்பு AOP module-க்கு உள்ளது.

விரிவான பயன்பாட்டுக்கு GitHub-ஐப் பாருங்கள்.

ஒரு நிகழ்வை எவ்வாறு தனித்துவமாக அடையாளம் காண்பது?

இரண்டு கேள்விகள் உள்ளன: நிகழ்வை எவ்வாறு வெளிப்படுத்துவது, அதன் தனித்துவத்தை எவ்வாறு உறுதிசெய்வது?

ஒரு நிகழ்வை வெளிப்படுத்துதல்

நிகழ்வுகள் event_path மூலம் வெளிப்படுத்தப்படுகின்றன. ஒரு நிகழ்வைத் தூண்டும் responder-க்கு, அதன் responder chain-ஐப் பின்தொடர்ந்து அந்தச் சங்கிலியின் path-ஐ உருவாக்குவதே மையக் கருத்து.

உருவாகும் responder path இப்படித் தெரியும்:

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate

நிகழ்வைத் தனித்துவமாக அடையாளம் காணுதல்

சில business சூழல்களில், ஒரே button அல்லது control அதன் பண்புகள் மாறும்போது வெவ்வேறு business நிகழ்வுகளைக் குறிக்கிறது.

உதாரணமாக, முகப்புத் திரை button வெளியேறிய நிலையில் உள்நுழையத் தட்டவும் என்றும், உள்நுழைந்த பின் அடையாளச் சரிபார்ப்பு முடியவில்லை என்றால் அடையாளத்தைச் சரிபார்க்கவும் என்றும் காட்டலாம்.

அதே button-க்கு view tree மாறவில்லை; எனவே உருவாகும் responder path-உம் மாறாது.

இதே போன்ற business சூழல்களில் UISwitch-ன் on/off நிலை, UISegmentedControl-ன் indexSelect பண்பு, UIStepper, மேலும் UITableView அல்லது UICollectionView-இல் cell தொடர்புகள் அடங்கும்.

இதைக் கையாள, WKTrackingData ஒரு event_path-ஐ உருவாக்கும்போது control-ன் பண்புகளைத் தேர்ந்தெடுத்துச் சேர்க்கிறது. உருவாகும் event_path இவ்வாறு இருக்கும்:

"event_path" = "#buttonClick:#UIButton#UIButton[0]#UIView[0]#ViewController#...#UIApplication#AppDelegate#currentTitle=Button#state=1#enabled=1#selected=0";

Business-க்கான விரிவாக்கங்கள்

இன்னொரு சூழலைப் பாருங்கள்: முகப்புத் திரையில் banner carousel.

ஒவ்வொரு banner இடத்திற்கும் server வழங்கும் படமும் செல்ல வேண்டிய url-உம் உள்ளன; அவற்றின் இடங்களையும் அமைக்கலாம்.

இங்கே ஒவ்வொரு index-இலும் இருக்கும் banner-க்கு நிலையான இலக்கு இல்லை. 0 இடத்திலுள்ள நிகழ்வை event_path மட்டும் கொண்டு தீர்மானிக்க முடியாது.

நிகழ்வைத் தனித்துவமாகக் கண்டறிய url போன்ற business parameters-ஐச் சேர்க்க வேண்டும்.

WKTrackingData business parameter விரிவாக்கங்களையும் ஆதரிக்கிறது; அழைப்பாளர் தனிப்பயன் parameters-ஐச் சேர்க்கலாம்:

கண்காணிக்கக் கூடாத controls-ஐ wk_ignoreTracking மூலம் விலக்கலாம்:

self.slider.wk_ignoreTracking = YES;

பிற சிக்கல்கள்

வெவ்வேறு நிகழ்வுகளைக் கண்காணிக்க, WKTrackingData aspect-oriented அணுகுமுறையைப் பின்பற்றி runtime மூலம் methods-ஐ நேரடியாக swizzle செய்கிறது.

ஆனால் UIAlertView, UIActionSheet, UITableView மற்றும் UICollectionView கண்காணிப்புக்கு அவற்றின் delegate methods-ஐ swizzle செய்ய வேண்டும்.

• அந்த delegate class ஏற்கனவே method-ஐச் செயலாக்கியிருந்தால், அதை நேரடியாக 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 objects method-ஐச் செயலாக்காதபோது, tableView:didSelectRowAtIndexPath:-க்கு ஓர் implementation-ஐ கையால் சேர்த்தாலும் அது இயங்கவில்லை.

முதலில் வழக்கமான tableView:didSelectRowAtIndexPath: call stack-ஐப் பாருங்கள்:

இதில், UITableView ஒரு cell tap-க்கு பதிலளிக்க இந்த நான்கு methods-ஐ வரிசையாக அழைக்கிறது:

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

அழைப்பு வரிசையின்படி, UITableView உண்மையில் delegate class-ன் tableView:didSelectRowAtIndexPath: method-ஐ அழைப்பதற்கு முன் தனது _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect: method-ஐ முதலில் அழைக்கிறது.

நேரடியாக _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:-இல் breakpoint அமைத்து assembly-ஐப் பாருங்கள்:

அந்த delegate class உண்மையில் tableView:didSelectRowAtIndexPath:-ஐச் செயலாக்கியிருந்தால் அனைத்தும் சரியாக இயங்கி, tableView:didSelectRowAtIndexPath: அழைப்பு முடியும்.

ஆனால் delegate class ஆனது tableView:didSelectRowAtIndexPath:-ஐச் செயலாக்காதபோது, tableView:didSelectRowAtIndexPath:-க்கு கையால் ஓர் implementation சேர்த்தாலும் tableView:didSelectRowAtIndexPath:-க்குப் பதிலளிக்க முயற்சியே நடைபெறாது.

Assembly-ஐப் பின்தொடர்ந்தால் வேறொரு instruction-க்கு நேரடியாக jump ஆகிறது.

WKTrackingData இங்கே வேறு அணுகுமுறையைப் பயன்படுத்தி, [UITableView _userSelectRowAtPendingSelectionIndexPath:]-ஐ நேரடியாக swizzle செய்கிறது (UICollectionView-க்கும் ஒத்த வழி). இதனால் delegate object தொடர்புடைய cell event method-ஐச் செயலாக்காதபோதும் UITableView, UICollectionView தொடர்புகளைக் கண்காணிக்க முடியும்.

4. நிறைவுச் சிந்தனைகள்

ஒரே நிகழ்வுக்கு பல event_path மதிப்புகள்

திரைகளில் சிறிய வேறுபாடுகள் உள்ள பல வெளியிடப்பட்ட versions-ஐ நினைத்துப் பாருங்கள். ஒரே நிகழ்வுக்கு பல event_path மதிப்புகள் இருக்கலாம்.

நடைமுறையில் இந்த mapping-க்கு server-side colleagues உதவி தேவை. Backend-இல் அமைக்கக்கூடியதாக மாற்றலாம்.

நிகழ்வு analytics-ஐ மேம்படுத்துதல்

மேலுள்ள Business-க்கான விரிவாக்கங்கள் பகுதி business parameters சேர்ப்பதை விவரித்தது. WKTrackingData இதை categories மூலம் செயலாக்குகிறது.

நடைமுறையில் full-event tracking அதிக bandwidth-ஐ வீணாக்கியது. பல நிகழ்வுகள் தேவையற்றவை [(ŏ_ŏ)].

மேலும் மேம்படுத்த, அனுப்ப வேண்டிய எல்லா நிகழ்வுகளையும் பட்டியலிடும் configuration file-ஐ server அனுப்பலாம். அதனுடன் பொருந்தும் event_path நிகழ்வுகள் மட்டுமே பதிவேற்றப்படும்.

இந்த கட்டத்தில் business parameters-ஐ WKTrackingData இல்லாமல்கூடப் பெறலாம்: நேரடியாக kvc-ஐப் பயன்படுத்துங்கள்.

உதாரணம்:

key_path = "viewController.banner.url"

இவ்வளவு படித்திருந்தால், WKTrackingData-ஐத் திறந்து ஒரு star கொடுங்கள். கேள்விகள் இருந்தால் GitHub-இல் issue ஒன்றைத் திறக்கவோ கீழே comment செய்யவோ செய்யுங்கள்!