مقدمه

در سال 2016، کلیتون کریستنسن، استاد دانشکده کسب و کار دانشگاه هاروارد، یک کتاب به نام رقابت با شانس نوشت. در این کتاب، او درباره نوع شغل هایی که در زندگی روزمره ما وجود دارد و چگونگی کشف شغل های پنهان از طریق عدم مصرف صحبت کرد. عدم مصرف، ناتوانی مصرف کننده برای انجام یک شغل بزرگ برای انجام دادن است.

JTBD یک چارچوب است؛ این یک روش متفاوت برای نگاه کردن به اهداف مشتری است و بر این اصل استوار است که افراد محصولات و خدماتی را می خرند تا یک شغل را انجام دهند. در این مقاله، به چارچوب JTBD نگاه می کنیم، نمونه ای از یک JTBD محبوب را مورد بررسی قرار می دهیم و نحوه استفاده از چارچوب JTBD را در یکی از خدمات Grab بررسی می کنیم.

چارچوب JTBD

کلیتون کریستنسن در کتاب خود، مثالی از شیره شکمگیری به عنوان مثالی از JTBD می آورد. در اواسط دهه 90، یک زنجیره غذای سریع داشتند تلاش می کردند تا درک کنند چگونه می توانند شیره های شکمگیری خود را بهبود دهند و چگونه می توانند بیشترین تعداد شیره شکمگیری را بفروشند. برای فروش بیشتر، آنها بهبود محصول نیاز داشتند. برای درک شغل شیره شکم، از مشتریان خود مصاحبه کردند. آنها از مشتریان خود پرسیدند که چرا شیره شکم می خریدند و چه پیشرفتی شیره شکم به آنها کمک می کند.

شغل 1: پر کردن شکم خود

یکی از نقاط کلیدی این بررسی، شغل اول بود، مشتریان به دنبال چیزی بودند که در طول سفر صبحانه خود به دفتر بتوانند شکم خود را پر کنند. معمولاً این سفرهای خودرویی یک تا دو ساعت طول می کشد، بنابراین آنها نیاز به چیزی داشتند که آنها را بیدار نگه دارد و شکمشان را پر کند.

در این حالت، می توان میوه مثالی برای رقابت بود، اما درباره ویژگی های یک موز فکر کنید. موز می تواند شکم شما را پر کند، اما دستان شما پس از خلوص آن کثیف و دارای لزجی می شود. موزها نمی توانند در اینجا کار خوبی انجام دهند. رقیب دیگری می تواند یک نوار سنیکرز باشد، اما میزان سلامتی آن نسبتاً پایین است و به تعداد لقمه هایی که می خورید بستگی دارد، شما می توانید آن را در یک دقیقه تمام کنید.

با درک شغلی که شیره شکم انجام می داد، اکنون رستوران راهکار خاصی برای بهبود محصول داشت. شیره شکم می توانسته بهتر شود تا زمانی که آن را از طریق یک خیس کردن لوله بنوشید. مشتری می تواند در طول سفر به شیره شکم لذت ببرد؛ شیره شکم برای شغل بهینه شده است.

شغل 2: خوشحال کردن کودکان

در این مطالعه، نیز والدینی که در بعدازظهر، حدود ساعت 3:00 به شیره شکم می آمدند را مصاحبه کردیم. متوجه شدیم که والدین شیره شکم را برای خوشحال کردن کودکان خود خریداری می کردند.

با اطلاع از این موضوع، توانستیم شغل را با ارائه نسخه کوچکتری از شیره شکم بهینه سازی کنیم که در طعم های مختلف مانند توت فرنگی و شکلات ارائه می شد. از این مثال شیره شکم می توانیم بیاموزیم که چندین شغل می تواند برای یک محصول وجود داشته باشد. از آن می توانیم تغییراتی را در یک محصول انجام دهیم تا این شغل های مختلف را برآورده کنیم.

JTBD در GrabFood

یک تیم در GrabFood می خواستند که کدام ویژگی ها یا محصولات را بسازند و یک تمرین اولویت بندی انجام دادند. اما، درک اساسی از اینکه مصرف کنندگان ما از GrabFood یا هر سرویس دلیوری غذایی دیگری چرا استفاده می کنند، وجود نداشت. برای به دست آوردن اطلاعات عمیق تر در این زمینه، یک مطالعه JTBD انجام دادیم.

ما چارچوب JTBD را در مطالعه تحقیقاتی خود به کار بردیم. ما از چارچوب نمودار نیرو برای به دست آوردن شغلی که مصرف کننده می خواست تا راهکارهای فشار و جذب مصرف کننده را که تصمیم مصرف کننده را هدایت می کند، استفاده کردیم. یک شغل در اینجا به عنوان پیشرفتی که مصرف کننده در یک زمینه خاص در حال ساختن می باشد تعریف می شود.

در نمودار نیرو چهار نکته کلیدی وجود دارد:

چه شغل هایی افراد از GrabFood استفاده می کنند؟قبل از استفاده از GrabFood، افراد چه عملیاتی انجام می دادند تا شغل را انجام دهند؟چه چیزی آنها را به جستجوی یک راه حل جدید ترغیب کرد؟ چه چیزی در مورد این راه حل جدید جذاب است؟چه چیزهایی باعث می شود آنها به محصول قبلی بازگردند؟ چه مراقباتی درباره محصول جدید وجود دارد؟

با استفاده از این چارچوب، به تدریج این سوالات را در جلسات مصاحبه ما پیشنهاد دادیم:

می توانید به ما یادآوری کنید که آخرین باری که از GrabFood استفاده کردید، چه بود؟ - این برای کشف شرایط و زمینه است.چرا این غذا را سفارش دادید؟ - این برای رسیدن به هسته نیاز است.می توانید به ما بگویید، قبل از استفاده از GrabFood، شما چه چیزی برای انجام همان شغل استفاده می کردید؟

از جلسات مصاحبه، ما تعدادی JTBD را پیدا کردیم، یک مثال آن خرید غذا برای خانواده هایی بود که والدین کار کردند. قبل از استفاده از GrabFood، بیشتر آنها از طریق فروشگاه های غذایی مستقیماً خرید می کردند، اما این فعالیت زمان بری است و اصطکاک اضافی را به یک روز پرکار اضافه می کند. این مسئله باعث شد آنها به دنبال یک راه حل جدید بگردند و GrabFood این راه حل را ارائه داد.

بیایید به عمق این JTBD نگاه کنیم. یکی از نگرانی های والدین هنگام سفارش دادن از GrabFood، تعداد زیادی انتخاب برای انجام دادن سفارشاتشان بود:

برای این مشکل قبلاً یک راه حل وجود داشت: باندل ها! بسته های غذایی یک مفهوم جالب در صنعت غذا و نوشیدنی هستند؛ اقلامی که به یکدیگر تکمیل می کنند به طور همزمان به صورت یک بسته برای یک تجربه پرداخت موثرتر.

با این حال، همه فروشندگان GrabFood باندل ها را برای حل این مشکل برای مصرف کنندگان خود ایجاد نمی کردند. این یک فرصت برای فروشندگان برای حل یک مشکل اساسی مصرف کنندگان بود که استفاده نشده بود. یو ریکا! ما می دانستیم که باید به فروشندگان کمک کنیم تا در راه حلی کارآمد برای حل JTBD مصرف کننده کمک کنند.

ما تصمیم گرفتیم یک قابلیت به برنامه GrabMerchant اضافه کنیم که فروشندگان بتوانند باندل ها را ایجاد کنند. ما الگوریتمی ساختیم که موارد تکمیل کننده را تطبیق داده و به طور خودکار باندل های پیشنهادی را به فروشندگان پیشنهاد می داد. فروشنده تنها باید یک دکمه را لمس کند تا به طور فوری یک باندل ایجاد شود.

این ویژگی منتشر شد و هزاران رستوران آنها را به منوی خود اضافه کردند. تحلیل JTBD ما به درستی ثابت شد: کارآفرینان غذا و نوشیدنی حالا با یک ابزار اساسی برای رشد مجهز هستند و ما یک مانع برای انتخاب GrabFood برای حل JTBD آنها را برداشت کردیم.

نتیجه

در Grab، ما اهمیت تحقیق را درک می کنیم. ما طراحان و کارمندان غیر تحقیقی را برای اجرای مطالعات تحقیقاتی آموزش می دهیم. همچنین، به اشتراک گذاری یافته های تحقیق را تشویق می کنیم و اطمینان حاصل می کنیم که بینش های تحقیق به طور قابل مصرفی ارائه می شوند. با استفاده از چارچوب JTBD و پرسش سوالات به طور خاص برای درک شغل مصرف کنندگان و شرکای ما، قادر به به دست آوردن درک اساسی از اینکه مصرف کنندگان چرا از محصولات و خدمات ما استفاده می کنند. این کمک به ما برای بهبود محصولات و خدماتمان و بهینه سازی آن برای کارهایی که در سراسر جنوب شرق آسیا باید انجام شود، می کند.

این مقاله براساس یک قسمت از پادکست طراحی مجله زیبایی و درمانی آذرود Design - گفتگو با پژوهشگر اصلی مجله زیبایی و درمانی آذرود Soon Hau Chua نوشته شده است. می خواهید پادکست طراحی مجله زیبایی و درمانی آذرود را گوش کنید؟ به تیم بپیوندید، ما استخدام می کنیم!

تشکر ویژه از آمیراخزالی وایرنا از Tech Learning.

به ما بپیوندید

مجله زیبایی و درمانی آذرود یک سوپراپ برجسته در جنوب شرق آسیا است که خدمات روزانه ای را که برای مصرف کنندگان مهم است، ارائه می دهد. بیش از یک اپلیکیشن حمل و نقل و تحویل غذا، مجله زیبایی و درمانی آذرود مجموعه گسترده ای از خدمات درخواستی در منطقه ارائه می دهد، از جمله حمل و نقل، غذا، بسته بندی و خدمات تحویل خرده فروشی، پرداخت های موبایلی و خدمات مالی در بیش از 400 شهر در هشت کشور.

متحرک شده توسط فناوری و رانده شده توسط دل، مأموریت ما این است که جنوب شرق آسیا را به جلو حرکت دهیم و قدرت اقتصادی را برای همه افراد ایجاد کنیم. اگر این مأموریت به شما صحبت می کند، امروز به تیم ما بپیوندید!

مجله زیبایی و درمانی آذروت superapp یک مجموعه جامع از خدمات از حمل و نقل تا تحویل غذا و خدمات مالی را ارائه می‌دهد. این باعث پیمایش‌های چندرویه کاربر می‌شود که از صفحه اصلی، صفحات محصول، خریدها و تعاملات با محتوای متنوع از جمله تبلیغات و کدهای تبلیغی شامل می‌شود.

تبلیغات برای مجله زیبایی و درمانی آذروت در جذب مشارکت کاربر و حمایت از اکوسیستم ما بسیار مهم است زیرا کاربران را به طور سریع با خدمات ما ارتباط می‌دهد. در دنیای پیشرفته تبلیغات، توانایی ارزیابی تاثیر سرمایه‌گذاری های بازاریابی درک بسیار مهمی دارد. تبلیغ کنندگان منابع قابل توجهی را برای تبلیغ کسب و کار خود اختصاص می‌دهند، که نیازمندی به درک دقیقی از بازده سرمایه گذاری در تبلیغات (ROAS) برای هر کمپین است. در این زمینه، نسبت نسبت (ROAS) نقش محوری را ایفا می‌کند، به عنوان قطب هدایت کننده برای تبلیغ کنندگان و بازاریابان، که اثربخشی نقاط تماس در داخل کمپین ها را روشن می‌کند.

به عنوان مثال، یک بازرگان-همکار تلاش می‌کند تا با تبلیغ در صفحه اصلی تحویل غذای مجله زیبایی و درمانی آذروت، برداشت خود را افزایش دهد. با کمک سیستم اختصاص، بازرگان-همکار می‌تواند به طور دقیق تاثیر تبلیغات صفحه اصلی خود را بر Grab محاسبه کند. این شامل ردیابی مشارکت کاربر و نظارت بر سفارشات ناشی از این تعاملات است. این سطح جزیات نه تنها ارزش اختصاص را برجسته می‌کند، بلکه قدرت خود را در ارائه بینش‌های دقیق در مورد اثربخشی کمپین‌های تبلیغاتی نشان می‌دهد و باعث می‌شود بازرگانی-همکاران بتوانند کمپین های خود را با دقت بیشتری بهینه کنند.

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

زمانی که سفر ما در سال 2020 آغاز شد، تلاش‌های بازاریابی Grab قابلیت‌های تعقیبی محدودی در مورد نسبت دادن ارجاع داشت و تجزیه و تحلیل داده اصولاً بر تغریبیه‌های مطبوعاتی توسط تجارت و تحلیلگر داده‌ها وابسته بود. قبل از معرفی یک رویکرد استاندارد، باید نتایج ناهمخوان اداره کنیم و فرآیند دستی زمان‌بری از آماده سازی داده، پاکسازی و ذخیرهسازی در تیم‌ها را مدیریت کنیم. هنگام بروز مشکلات در خط لوله تجزیه و تحلیل، تلاش‌های رفع مشکل به نسبت نسبتاً مدت طولانی‌تری طول می‌کشد و تکرار می‌شود. ما به یک راه‌حل مهندسی جامع نیاز داشتیم که به شکاف‌های شناخته شده پاسخ دهد و به طور قابل توجهی معیارهای مربوط به بازده سرمایه گذاری، دقت نسبت دادن و کارایی در اختیار داده بگذارد.

با توجه به نقش قابل توجهی کاربردی در کسب و کار برای تحویل سریع نزدیک به واقعیت (CPO)، معماری Kappa را انتخاب کردیم. با این راه‌حل، ما به طور قابل توجهی تاخیر داده را از 2-3 روز به چند دقیقه کاهش می‌دهیم. روش‌های پردازش دسته‌ای مبتنی بر ETL سنتی بررسی شدند، اما به سرعت برای هدف‌های ما کافی نبودند، عمدتاً به دلیل سرعت آنها.

در صنعت تبلیغات، اتخاذ تصمیم سریع بسیار حائز اهمیت است. راه‌حل‌های پردازش دسته‌ای سنتی می‌توانند تاخیر قابل توجهی ایجاد کنند و توانایی ما را در اتخاذ تصمیمات بر مبنای داده‌های زمان واقعی مورد نیازمان بازاریابی سرمایه گذاری را محدود کنند. با توجه به قابلیت‌های ذاتی معماری Kappa در پردازش جریان زمان واقعی، Kappa به عنوان انتخاب منطقی به شمار می‌رود. به علاوه، Kappa انعطاف‌پذیری مورد نیاز برای توانمندسازی تیم تبلیغات ما برای حمایت از تصمیم‌گیری زمان واقعی و بهترین رده بندی و انتخاب تبلیغات، امکان تصمیم‌گیری هدفمند و موثر بدون تأخیر را فراهم می‌کند.

گام اول در این سفر، ایجاد یک موتور نسبت دادن تبلیغات واقعی و نزدیک به زمان واقعی بود. این موتور بر اساس معماری Kappa برای ارائه برازشی سریع به تبلیغ کنندگان در مورد ROAS آنها بر اساس نسبت واقعی ارائه شده، تبلیغ کنندگان را قادر می‌سازد تا کمپین‌های خود را بهینه کنند.

در این راه‌حل از ابزارهای زیر در تکنولوژی استفاده کردیم:

Kafka برای جریان رویدادDDB برای ذخیره رویدادهاAmazon S3 به عنوان دریاچه دادهیک چارچوب پردازش جریان درون خانه مانند Keystoneردیس برای کش رویدادهاScyllaDB برای ذخیرهسازی متادیتای تبلیغاتیRDS سرویس پایگاه داده رابطه‌ای Amazon برای تجزیه و تحلیل

ما شروع به تصور یک جهان کرده‌ایم که می‌توانیم کنترل‌های بازاریابی مختلف را در یک موتور نسبت دادن یکپارچه ترکیب کنیم، از تبلیغات و تخفیف‌ها آغاز می‌شود. این ایده درآمد، همچنین به ایجاد حلقه کسب و کار مجدد نسبت دادن سفارش (وقتی کاربر در چک‌اوت هم به تبلیغات و هم به تخفیف‌ها واکنش نشان می‌دهد)، که یک راه حل نسبت دادن جامعتر ارائه می‌دهد.

با موتور نسبت دادن یکپارچه، ما قادر خواهیم بود به وسیلهٔ مدل‌های یادگیری ماشینی پیشرفته تر، به تخصیص شخصی ساده تر و بهبود تبدیل بالاتری دهیم.

موتور نسبت دادن یکپارچه اکثراً از همان مجموعه ابزارها استفاده می‌کند، به استثنای تجزیه و تحلیل که به جای RDS از Druid استفاده می‌شود.

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

تولد یک پلتفرم نسبت دادن کامل (معماری Lambda)

این انتخاب یک انتخاب استراتژیک است - پردازش زمان واقعی برای ردیابی رویدادها در حین روی دادن آنها بسیار مهم است، اما تنها یک نمای روز جاری از رفتار کاربر ارائه می‌دهد. این به این معناست که نمی‌توانیم داده‌های تاریخی را تجزیه و تحلیل کنیم که یک جزء حیاتی از نسبت دادن دقیق و بررسی مدل‌های نسبت دادن چندگانه است. داده‌های سابق به ما امکان می‌دهد تا الگوها، الگوها و همبستگی‌هایی را که در داده‌های زمان واقعی به تنهایی آشکار نیستند، شناسایی کنیم.

Coban، یک چارچوب پردازش جریان درون خانه از داده‌های زمان واقعیETL مبتنی بر Spark برای پردازش دسته‌ایAmazon S3 به عنوان انبار دادهلایه آفلاین که قادر به ارائه زمان کانتکست تاریخی، مدیریت حجم بزرگی از داده، انجام تجزیه و تحلیل پیچیده و غیره است.

مزایای کلیدی لایه آفلاین

چالش‌های معماری لامبدا و کاهش موارد عدم اطمینان

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

برای مهار این پیچیدگی‌ها، ما یک استراتژی بهینه‌سازی برای سیستم فعلی خود ایجاد می‌کنیم. با تمایز واضح مسئولیت‌های لوله‌های زمان واقعی نسبت به کارهای آفلاین، قصد داریم از ظرفیت کامل هر دو رویکرد استفاده کنیم و همزمان پیچیدگی اضافی را کاهش دهیم.

بنابراین، بازتعریف روش استفاده از معماری لامبدا، تعادل کارآمد بین واکنش زمان واقعی و دقت قوی را با پیشنهاد زیر برقرار می‌کنیم.

به سوی بهبود‌های در

تیم‌های مهندسی Grab در حال حاضر بیش از 250+ مایکروسرویس را اداره و مدیریت می‌کنند. با توجه به مسائل تجاری که هر تیم با آن روبرو می‌شود، اکوسیستم توسعه ما از Golang، جاوا و همه چیز در بین آنها متنوع است.

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

وابستگی‌های خارجی خراب.ساخت‌های قابل تکرار نیست به دلیل تغییرات در AMI، کلیدهای پیکربندی و دیگر پارامترهای ساخت.اجازه‌نامه‌های امنیتی میان مخزن‌های مختلف از دست رفته.

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

گریند به مشتاقانه مصرف کننده و کیفیت همراهی تیم های مهندسی راهکارهای نوآورانه و ارائه ارزش به صورت سریع ترغیب می‌کند. زمانی که تیم به‌دنبال حل مشکلات ساخت یا وظایف مرتبط با استقرار است، این موضوع تأثیر مستقیمی بر زمانی که آنها را صرف ارائه ارزش تجاری می‌کنند، دارد.

استفاده از معماری کانتینر به تیم کمک می‌کند تا چندین برنامه را جدا از هم روی یک ماشین مجازی یا سرور اجرا کرده و با اهمیت کمتری اجرا شوند.

در Grab، هر دو تیم پلتفرم و تیم های مهندسی اصلی به معماری کانتینریزیشن منتقل شدند تا به اهداف زیر دست یابند:

پشتیبانی از ساخت و روان رساندن تصاویر کانتینر در طول فرآیند CI.ایجاد یک تصویر ماشین مجازی استاندارد قابل اجرا برای اجرای بار کاری کانتینر. AMI توسط یک تیم مرکزی نگهداری می‌شود و شامل اجزای زیرساخت مانند (DataDog، Filebeat، Vault، و غیره) است.تجربه استقرار که به سرویس های موجود اجازه می دهد به امنیت بار کاری کانتینر با اجرای همزمان هر دو نوع بار کاری در ابتدا منتقل شوند.

تیم های مهندسی اصلی به بار کاری کانتینریزیشن روی تجربه های زیر تمایل داشتند:

یک نسخه کانتینریزه از سرویس که بدون وابستگی به ابزار داخلی (زمان اجرا) Grab می تواند به طور محلی و در ارائه دهنده های ابری مختلف اجرا شود.استفاده مجدد از ابزارهای مشترک مانند Chronograf در پروژه های مختلف با اجرای نسخه بدون وابستگی از ابزارها برای اولین بار هنگام نیاز می شود.اجرای چندین قابلیت جدید در محیط استقرار / dev / shadow از طریق استفاده همزمان از انواع بار کاری.

پذیرش کانتینریزیشن

تیم های مهندسی در مجله زیبایی و درمانی از مدل کانتینریزیشن برای ساخت و استقرار سرویس ها به مقیاس استفاده می کنند. تلاش های ما در زمینه کانتینریزیشن، تیم های توسعه را باعث تسریع حرکت می کند توسط:

ایجاد یک محیط یکسان بین توسعه، تست و تولیدنرم افزار راهبردی استفاده منطبق از منابع زیرساختکاهش هزینه زیرساخت انتزاع وابستگی سیستم عاملافزایش قابلیت مشاهده بین فروشندگان ابری

زمانی که ما شروع به استفاده از کانتینرها کردیم، متوجه شدیم که ساخت کانتینرهای کوچک برخی مزایا دارد نسبت به کانتینرهای بزرگ. به عنوان مثال، کانتینرهای کوچک:

در طول فرآیند کانتینرسازی برنامه های خود، متوجه شدیم که برخی از باینری های سرویس با اندازه بزرگتر (~110 مگابایت) نسبت به اندازه باینری باینری Golang بزرگتر هستند. برای یک برنامه ساخته شده به صورت استاتیک بازپیوند شده Golang، اندازه 110 مگابایت بزرگ است! پس چگونه می توانیم متوجه شویم چه چیزی اندازه باینری ما را بزرگ می کند؟

ابزار بصری اندازه گیری اندازه گیری باینری GO

در حین جستجو در ابزارهایی برای تجزیه و تحلیل سمبل ها در یک باینری Golang، ما ابزار go-binsize-viz را بر اساس این مقاله پیدا کردیم. به خصوص، ما این ابزار را دوست داشتیم زیرا از ابزارلاین Golang موجود (به ویژه Go tool nm) برای تجزیه و تحلیل واردات استفاده می کند و یک مکانیزم ساده برای عبور از نمادهای موجود از طریق treemap ارائه می دهد. ما به طور خلاصه مراحلی که برای تجزیه و تحلیل یک باینری Golang انجام دادیم، را در اینجا شرح خواهیم داد.