پیاده‌سازی Deferred DeepLink‌ها

دو سه روز پیش توی شرکت به عنوان یه تسک فرعی، در مورد امکان پیاده‌سازی Deferred DeepLinkها توسط خودمون یه تحقیق یکی دو ساعته کردم، چون خروجیش رو وقتی برای بچه‌های شرکت نوشتم شبیه مقاله شد، گفتم اینجام بذاریم شاید برای فرد دیگه‌ای هم جذاب بود. اگر شمام نظری داشتید میتونید در قسمت نظرات بنویسید.

عکس برای یه مقاله در سایت innovationm.co می‌باشد.
عکس برای یه مقاله در سایت innovationm.co می‌باشد.


وقتی کاربر روی یه DeepLink کلیک میکنه، براساس اینکه App روی دستگاهش نصب باشه یا نه؟! دو حالت پیش میاد:

۱- اپ (App) نصب هست: توی این حالت کاربر روی لینک کلیک میکنه و توسط App به صفحه‌ای مشخص شده توسط لینک منتقل میشه. بهش Direct DeepLink میگن.

۲- اپ (App) نصب نیست: توی این حالت چون کاربر App رو نداره، با زدن روی لینک به Store منتقل میشه، و بعد از نصب، وقتی اپ رو اجرا کرد به همون صفحه مشخص شده توسط لینک منتقل میشه. لینک‌های این مدلی رو Deferred DeepLink میگن. نکته مهم اینه اینجوری نیست که اینجور لینک‌ها در ۱۰۰درصد موارد کار کنند! احتمال داره گاهی کاربر روی لینک بزنه و بعد نصب بره توی App ولی به جای خاصی منتقل نشه. (در ادامه دلیلشو میگم)

هم Firebase و هم Branch.io دو حالت رو پشتیبانی میکنن. اگر بخوایم خودمون همه چیو پیاده‌سازی کنیم، حالت اول که سادس و میتونیم بدون دردسر خاصی پیاده کنیم، ولی پشتیبانی از Deferred DeepLink نیاز به کار و تست بیشتری داره. مخصوصا که یه چیز ۱۰۰درصدی نیست و همیشه باید تلاش کنی درصد مواردی که لینک کار میکنه رو بالاتر ببری.

جزییات پیاده‌سازی

نحوه‌ی پیاده‌سازی Deferred DeepLinkها اینجوریه که وقتی کاربر روی لینک کلیک میکنه و توی مرورگر به سایت میره، اونجا یه سری اطلاعات ازش مثل مدل دیواس، آی‌پی، سایز اسکرین، سیستم‌عامل، نسخه‌سیستم‌عامل و … رو نگه میدارن. بعد وقتی کاربر اپ برای اولین‌بار اپ رو باز میکنه، دوباره همین اطلاعات رو توسط اپ به سرور میفرستن، اگر دیدن کسی با این اطلاعات قبلا روی لینکی کلیک کرده، میفهمن این همون یوزر هست و به اون صفحه‌ای که لینک مشخص کرده منتقلش میکنن. هرچقدر این Match شدن‌ها درست باشه، نشون میده کیفیت پیاده‌سازی بالاتر بوده. گاهی اوقات کاریش نمیشه کرد دیگه، مثلا کاربر روی لینک کلیک میکنه، بعد مثلا VPN وصل میکنه IPش عوض میشه، بعد میاد App رو باز میکنه!! توی این حالت خب اون Matching درست نمیشه با اینکه واقعا این همون کاربر هست.

این چیزی که گفتم حالت کلی پیاده‌سازی بود. حالا با روش‌های کمکی و یا سری کانفیگ‌ها سعی میکنن درصد Match شدن رو بالاتر ببرن.

بخوام یه مثال از کانفیگ بزنم، مثلا میتونه کم کردن یا زیاد کردن بازه‌ی Matching بین اطلاعات باشه، مثلا آخرین اطلاعاتم از فایریس اینه تا ۱ ساعت کاربر اگر بعد نصب App رو اجرا کنه، امکان داره Matching پیش بیاد و به صفحه خاصی که نیازه منتقل بشه. ولی بیشتر از این دیگه کار نمیکنه. این تایم برای Branch.io دو ساعت هست.

بخوام یه مثال از روش کمکی بگم که به بالا رفتن Matching توی کمک میکنه (البته توی اندروید) اینه که گوگل‌پلی یه چیزی به اسم INSTALL_REFERRER داره و گوگل‌پلی میتونه بعد نصب یه سری پارامتر رو باهاش به App بده. مقاله زیر خیلی خوب پیاده‌سازی Deferred DeepLink رو با این قابلیت گوگل‌پلی توضیح داده.

https://www.linkedin.com/pulse/android-deferred-deep-link-hamid-sedghi-n/

سرویس‌هایی مثل Branch.io ترکیب همه روش‌ها با هم استفاده میکنند. حتی Branch.io یه روش داره که فقط بکار سرویس‌هایی میاد که اپ‌های زیادی ازشون استفاده میکنن و اگر ما پیاده‌ کنیم خیلی سودی نبریم. در کل این دو تا مقاله Branch.io خیلی عالیه. اگر علاقمندید بخونید:

https://blog.branch.io/the-importance-of-matching-accuracy-in-deep-linking

https://blog.branch.io/deferred-deep-linking-with-device-snapshotting