Exciting News:
Madkudu lands $18M Series A led by Felicis to accelerate PLG adoption
Read Now!

MadKudu as Your Next Best Content Recommendation Engine

What should I say? I’m not sure what to do with my hands…

Are your reps (or even worse, maybe your Growth or DemandGen teams) like Ricky Bobby when he’s asked to speak into the mic? Or, maybe more like Bridget Jones introducing Mr. Fitzherbert? One of the top questions we get at MadKudu is, “How can I tell my SDRs, BDRs and AEs what their next best touch, cadence or nurture track should be?”

Though you can definitely use the tools in MadKudu platform to get a solid idea of what events (and thus product-related content) historically correlates to paid conversion from trial, the problem usually reduces down to what content, feature-related messaging, web pages and emails have been created and curated by your Growth, Product, and DemandGen teams and then what would be best to send or offer them next.

Additionally, not only do you need to know what content is available, but also how that content is organized and tracked so you can establish the relative interest a user, prospect, or even more importantly a product qualified lead has in that content and can therefore effectively offer the next best content that may expand their product interest and engagement.

Finally, standard tooling within CRMs and even MAPs do not usually provide you with a structured way of tracking and tabulating that relative interest in order to effectively rank and prioritize the content that you have to hand, let alone the total content that has been engaged with in a non-linear fashion.

In this article we’ll explore how you can leverage MadKudu (along with a bit of inquiry, organization and classic Ops ingenuity) to organize, prioritize, and dynamically designate your next best content to SDRs, BDRs, and AEs, or potentially even automate those content offerings via dynamic nurtures. The final output being a single field called Content Decision Computation that highlights the specific piece of content that should next be sent to the prospect or qualified lead. This might be used by marketing for nurtures, sales for cadences, or by product for in-app messaging. Bottom line, we're seeking to narrow down and facilitate relevant conversations. So let's get into it!

Laying the Groundwork - Content Categorization and Related Aggregations

One of the most challenging things to do with content is to map it to the Buyer Journey. This isn’t because the concepts of Awareness, Consideration, and Decision are inherently tricky or confusing. In fact, when one reads a whitepaper, email, webpage, or random piece of tradeshow collateral, it’s usually pretty clear what stage of the journey the piece is targeted to, but it requires just that… really reading it!

The next point of confusion that surfaces is that the content might slightly drift one way or the other, up or down the awareness stages. So, the only solution there is to just make a decision (yes, somewhat arbitrarily) about where it will sit. The primary point of evaluation that we normally use to draw relative lines in the sand are the depth, detail and granularity of the content. Or, it might be the degree of technical nomenclature specific to the product or service leveraged in the piece being explored. The more the “what?” versus the “why?” the further toward decision you should be and vice-versa in the direction of awareness.

Product Engagement Stages

Bottom line, be willing to make a decision and just stick to it. This concept is extended to product-led growth by categorizing the actions users can take and the content they can consume as related to their overall journey in becoming an experienced user, advocate and power user of the product. These Product Engagement Stages might look something like:

  • Setup - The actions required to sign up for and establish first use of a product in the trial or free version and even begin using it.
  • User - The initial actions of truly using the free platform at a basic level and beginning to get value from doing so.
  • Sharing - The promotional, external, and invitational actions that can be monitored when a user begins to export or leverage the product in front of or in coordination with others - either inside or outside the free product org.
  • Power User - Those actions that begin to show a true mastery of the features available and possibly combinations of various more basic actions with the platform.
  • Admin - User creation, deletion, cleanup and maintenance actions (if available and monitored) can be indicators of deep engagement and preparation for upgrade/expansion to a paid self-serve or even enterprise level.

We’ll continue to use the above in our discussion from here on out. Why? Because, we’ve made the decision to. You may have more or fewer categories, but whatever they are, be willing to make decisions around how the following items are classified across them and then at least stick to them for a few months at a time. You’re next going to want to categorize the various actions and content you have available across the primary places that your users are engaging (and will be invited to engage).

  • Product
  • Web (includes website, support, product blog and community pages)
  • Email

This would then give you items for tracking and aggregation as follows.

Setup

  • Product 1
  • Product 2
  • Web 1
  • Web 2
  • ….
  • Email 1
  • Email 2

User

  • Product 1
  • Product 2
  • Web 1
  • Web 2
  • ….
  • Email 1
  • Email 2

And so on as above, for all Product Engagement Stages. This will eventually result in an overall structure of the logic, later expressed in SQL code to be used in your final Content Decision Computation, that breaks down the overall tracks and features of the content. Expressed visually by our Solutions Engineering team as below.

Content Decision Computation - Structure and Schema

NOTE: Email should only be leveraged in the above in response to Email CTAs and click-throughs. Tracking and grouping opens or sends at this level would give many false positives to your counts. Though, we do want to track sends from an administrative perspective within the CRM or MAP. More on that later!

The Dirty Work

Now, go get yourself a spreadsheet and a big list of all your content and the links to it and categorize everything into one of the above buckets! Making the spreadsheet is easy and should take you a few minutes. Culling all the content, reading it, evaluating it and aligning with sales and marketing on the categorizations you’ve proposed shouldn’t take you more than a month (alright maybe two) with any sort of concerted effort. If you need help and are a MadKudu customer, feel free to let our Professional Services team know and they may be able to get you unstuck. We think you got this though.

Time Bounding

The above would also be your first set of aggregations to track within MadKudu. The number of actions in the above categories over the last 30, 60 or 90 days, depending on your median level of product and web engagement for regular users would be the appropriate period of time with which to bound the aggregations.

For examples and more on aggregations in MadKudu, check out these articles on Aggregations in our Support Portal.

Product Engagement Stage Super-Aggregations and Track Decision Computations

Next, you need to push your aggregations out to mapped fields in your CRM or DWH so that, for each lead and contact, you would be able to report on what product events and content have been taken advantage of. Then, the question is whether you wish to consolidate those aggregations and sum the values into a single Product Engagement “Super-Aggregation.” Where exactly you choose to do this is up to you. You can definitely execute the logic within MadKudu after pulling the values previously saved and pushed out back in from your CRM or DWH.

Regardless, the field names for this computation would be something like the following:

  • setup_total 
  • user_total
  • sharing_total 
  • setup_total
  • power_user_total
  • admin_total

For examples and more on computations in MadKudu, check out these articles on Computations in our Support Portal.

The decision to build the logic within your CRM or DWH as opposed to loop it back into MadKudu might be due to a need to deliver these aggregations within a very short span of time - nominally less than 24 hours. If you are going to offer the potential lead any sort of breathing room at all before reaching out to them, you should definitely consider formulating the logic within MadKudu as its flexibility around custom computations could be put to great effect. We discuss the specific timeline implications of running the overall processes between your stack components in summary at the end of the article.

Feature Engagement Aggregations - Specific Content Granularity

See what we did there? We just made this into a decision-focused article (if it wasn’t one before). But again, we’re looking at how we can do exactly that - enable the decision around what is the next best piece of content to offer up. Next, we’re going to need to categorize content at one level down - more granularly than before. This is so we can get to the specific content we’ll offer next. 

This is a feature-level aggregation and may not have more than three or four events monitored within each one, but should map to the specific default order of content if you were to produce a fully linear journey of product engagement stages and the features that would be taken advantage of within each of those steps. For the sake of this example (again, because we say so…) we’ll go with four features according to their order of natural progression in terms of the product engagement journey, or potentially in order of their complexity and building one on top of the other within their product engagement stage. The full list of these Feature Aggregations would therefore be:

Aggregations for Setup - Feature Engagement

  • Setup - Feature 1 (setup_feature_1)
  • Setup - Feature 2 (setup_feature_2)
  • Setup - Feature 3 (setup_feature_3)
  • Setup - Feature 4 (setup_feature_4)

Aggregations for User - Feature Engagement

  • User - Feature 1 (user_feature_1)
  • User - Feature 2 (user_feature_2)
  • User - Feature 3 (user_feature_3)
  • User - Feature 4 (user_feature_4)

And so on as above, for all Features within all Product Engagement Stages.

What the Hell did We Send Them?

In order to facilitate a final Content Decision Computation also requires checking to see if that content has not yet been sent. This is a component of the logic you’re building that requires some old school campaign tracking and a Flow in the CRM at a minimum to stamp the fact that specific content has been received. 

In order to effectively track this within the CRM and to leverage the MadKudu integration via Event Mappings, we recommend setting up campaigns for each of your content emails or communications and specific campaign member statuses for each of the following.

  • Sent - We recommend using a custom status eg “Email Sent” as MadKudu’s mapping boilerplate hard-excludes “Sent” campaign member statuses to avoid dirty data.
  • Clicked (required to measure clear response or CTA engagement)

NOTE: When using MadKudu, be sure to set Email Activity mapping on “Email Sent” and set points to 0 in LTB model so as to avoid scoring leads and contacts up inadvertently.

Though MadKudu could be used to track the action as a boolean within a specific time bounding using a boolean aggregation and would do just fine with that, it would be limited to that timespan eventually dropping off and in full disclosure, MadKudu doesn’t currently allow for the push of boolean aggregations to external systems - currently, only numeric aggregations can be exported.

So, for the tracking of your content permanently, you will need to establish a set of fields (one for each specific content piece in the collection you wish to track) on a custom object in the CRM or DWH, or more simply (but at the risk of offending your CRM Admin) on the lead and contact objects. In all reality, you’re only going to want to track, as in this example, 20 or fewer total campaigns at this level of granularity, so you should be fine. Sidenote, please don’t add them to page layouts! To allow for additional functionality and evaluation of recency if taking this route, we recommend a Date Sent field to match all your Feature Engagement aggregations. The set would be something like:

  • Date Sent - Setup - Feature 1 (setup_feature_1_sent)
  • Date Sent - Setup - Feature 2 (setup_feature_2_sent)
  • Date Sent - Setup - Feature 3 (setup_feature_3_sent)
  • Date Sent - Setup - Feature 4 (setup_feature_4_sent)
  • Date Sent - User - Feature 1 (user_feature_1_sent)
  • Date Sent - User - Feature 2 (user_feature_2_sent)
  • Date Sent - User - Feature 3 (user_feature_3_sent)
  • Date Sent - User - Feature 4 (user_feature_4_sent)

And so on as above, for all Features within all Product Engagement Stages.

Once you have the above fields in place, you will be able to track the content that was not only engaged with as in the previous aggregations described, but permanently track the content that was sent or offered to a user, prospect, or product qualified lead and thus avoid redundant reading or viewing once proffered.

Picking a Winner - Content Decision Computation

The final output you will need to establish is the Content Decision Computation. In evaluating and tracking the engagement across the various Product Engagement Stages and the content mapped to each of them, you will want to pick the winner. Depending on your level of comfort and priority, you could execute this via a computation in MadKudu or populate the field by running a Flow Loop in your CRM, or potentially running a scheduled query on your DWH. Each one of these would allow you to look through the values for each of the Product Engagement Stages, the Feature Engagement aggregations, and pick the winner in terms of the highest score and only when that content has not been sent.

We’ve provided the final computation logic needed to perform the evaluation, courtesy of the MadKudu Solutions Engineering team. The sample code to return the final decision for track and content would be something like the below.


CASE 

-- Setup Stage

WHEN

    -- Assessing whether the Setup Stage has the highest activity level

    setup_total > user_total AND setup_total > sharing_total 

    AND setup_total > power_user_total AND setup_total > admin_total

    -- Making sure that the Setup Stage Track is not completed yet

    AND (setup_feature_1_sent IS NULL OR setup_feature_2_sent IS NULL 

        OR setup_feature_3_sent IS NULL OR setup_feature_4_sent IS NULL) 

THEN     

    -- Testing which content track has not been sent yet

    CASE 

        WHEN setup_feature_1_sent IS NULL AND setup_feature_1 >= setup_feature_2 AND setup_feature_1 >= setup_feature_3 AND setup_feature_1 >= setup_feature_4 THEN 'Send Setup - Feature 1'

        WHEN setup_feature_2_sent IS NULL AND setup_feature_2 >= setup_feature_1 AND setup_feature_2 >= setup_feature_3 AND setup_feature_2 >= setup_feature_4 THEN 'Send Setup - Feature 2'

        WHEN setup_feature_3_sent IS NULL AND setup_feature_3 >= setup_feature_1 AND setup_feature_3 >= setup_feature_2 AND setup_feature_3 >= setup_feature_4 THEN 'Send Setup - Feature 3'

        WHEN setup_feature_4_sent IS NULL AND setup_feature_4 >= setup_feature_1 AND setup_feature_4 >= setup_feature_2 AND setup_feature_4 >= setup_feature_3 THEN 'Send Setup - Feature 4'

    END

-- User Stage

WHEN 

    -- Assessing whether the User Stage has the highest activity level

    user_total > setup_total AND user_total > sharing_total 

    AND user_total > power_user_total AND user_total > admin_total 


    -- Making sure that the Setup Stage Track is not completed yet

    AND (user_feature_1_sent IS NULL OR user_feature_2_sent IS NULL 

        OR user_feature_3_sent IS NULL OR user_feature_4_sent IS NULL) 

THEN     

    -- Testing which content track has not been sent yet

    CASE 

        WHEN user_feature_1_sent IS NULL AND user_feature_1 >= user_feature_2 AND user_feature_1 >= user_feature_3 AND user_feature_1 >= user_feature_4 THEN 'Send User - Feature 1'

        WHEN user_feature_2_sent IS NULL AND user_feature_2 >= user_feature_1 AND user_feature_2 >= user_feature_3 AND user_feature_2 >= user_feature_4 THEN 'Send User - Feature 2'

        WHEN user_feature_3_sent IS NULL AND user_feature_3 >= user_feature_1 AND user_feature_3 >= user_feature_2 AND user_feature_3 >= user_feature_4 THEN 'Send User - Feature 3'

        WHEN user_feature_4_sent IS NULL AND user_feature_4 >= user_feature_1 AND user_feature_4 >= user_feature_2 AND user_feature_4 >= user_feature_3 THEN 'Send User - Feature 4'

    END

-- Sharing Stage

WHEN 

    -- Assessing whether the Sharing Stage has the highest activity level

    sharing_total > setup_total AND sharing_total > user_total 

    AND sharing_total > admin_total AND sharing_total > power_user_total


    -- Making sure that the Setup Stage Track is not completed yet

    AND (sharing_feature_1_sent IS NULL OR sharing_feature_2_sent IS NULL 

        OR sharing_feature_3_sent IS NULL OR sharing_feature_4_sent IS NULL)  

THEN     

    -- Testing which content track has not been sent yet

    CASE 

        WHEN sharing_feature_1_sent IS NULL AND sharing_feature_1 >= sharing_feature_2 AND sharing_feature_1 >= sharing_feature_3 AND sharing_feature_1 >= sharing_feature_4 THEN 'Send Sharing - Feature 1'

        WHEN sharing_feature_2_sent IS NULL AND sharing_feature_2 >= sharing_feature_1 AND sharing_feature_2 >= sharing_feature_3 AND sharing_feature_2 >= sharing_feature_4 THEN 'Send Sharing - Feature 2'

        WHEN sharing_feature_3_sent IS NULL AND sharing_feature_3 >= sharing_feature_1 AND sharing_feature_3 >= sharing_feature_2 AND sharing_feature_3 >= sharing_feature_4 THEN 'Send Sharing - Feature 3'

        WHEN sharing_feature_4_sent IS NULL AND sharing_feature_4 >= sharing_feature_1 AND sharing_feature_4 >= sharing_feature_2 AND sharing_feature_4 >= sharing_feature_3 THEN 'Send Sharing - Feature 4'

    END

-- Power User Stage

WHEN 

    -- Assessing whether the Power User Stage has the highest activity level

    power_user_total > setup_total AND power_user_total > sharing_total 

    AND power_user_total > user_total AND power_user_total > admin_total 


    -- Making sure that the Setup Stage Track is not completed yet

    AND (power_user_feature_1_sent IS NULL OR power_user_feature_2_sent IS NULL 

        OR power_user_feature_3_sent IS NULL OR power_user_feature_4_sent IS NULL) 

THEN     

    -- Testing which content track has not been sent yet

    CASE 

        WHEN power_user_feature_1_sent IS NULL AND power_user_feature_1 >= power_user_feature_2 AND power_user_feature_1 >= power_user_feature_3 AND power_user_feature_1 >= power_user_feature_4 THEN 'Send Power User - Feature 1'

        WHEN power_user_feature_2_sent IS NULL AND power_user_feature_2 >= power_user_feature_1 AND power_user_feature_2 >= power_user_feature_3 AND power_user_feature_2 >= power_user_feature_4 THEN 'Send Power User - Feature 2'

        WHEN power_user_feature_3_sent IS NULL AND power_user_feature_3 >= power_user_feature_1 AND power_user_feature_3 >= power_user_feature_2 AND power_user_feature_3 >= power_user_feature_4 THEN 'Send Power User - Feature 3'

        WHEN power_user_feature_4_sent IS NULL AND power_user_feature_4 >= power_user_feature_1 AND power_user_feature_4 >= power_user_feature_2 AND power_user_feature_4 >= power_user_feature_3 THEN 'Send Power User - Feature 4'

    END

-- Admin Stage

WHEN 

    -- Assessing whether the Admin Stage has the highest activity level

    admin_total > setup_total AND admin_total > user_total 

    AND admin_total > sharing_total AND admin_total > power_user_total  


    -- Making sure that the Setup Stage Track is not completed yet

    AND (admin_feature_1_sent IS NULL OR admin_feature_2_sent IS NULL 

        OR admin_feature_3_sent IS NULL OR admin_feature_4_sent IS NULL) 

THEN     

    -- Testing which content track has not been sent yet

    CASE 

        WHEN admin_feature_1_sent IS NULL AND admin_feature_1 >= admin_feature_2 AND admin_feature_1 >= admin_feature_3 AND admin_feature_1 >= admin_feature_4 THEN 'Send Admin - Feature 1'

        WHEN admin_feature_2_sent IS NULL AND admin_feature_2 >= admin_feature_1 AND admin_feature_2 >= admin_feature_3 AND admin_feature_2 >= admin_feature_4 THEN 'Send Admin - Feature 2'

        WHEN admin_feature_3_sent IS NULL AND admin_feature_3 >= admin_feature_1 AND admin_feature_3 >= admin_feature_2 AND admin_feature_3 >= admin_feature_4 THEN 'Send Admin - Feature 3'

        WHEN admin_feature_4_sent IS NULL AND admin_feature_4 >= admin_feature_1 AND admin_feature_4 >= admin_feature_2 AND admin_feature_4 >= admin_feature_3 THEN 'Send Admin - Feature 4'

    END

END


Summary - MadKudu for MadScientists?

The above recommended solutions might seem circuitous, or infinitely loop-prone, but they basically seek to perform three primary actions.

  • Determine First Content Offer/Email
  • Determine the Next Best Content Offer/Email
  • If all content in a Track/Category is exhausted, send the next best content in the next best Track/Category.

The order of operations for the overall data flow would be as follows:

  1. Run aggregations on content/events mapped to Product Engagement Stages and export to DWH or SFDC.

  2. Concurrent with 1 - Run aggregations on content/events mapped to Feature Engagement and export to DWH or SFDC.

  3. Concurrent with 1 and 2 - Track booleans for content already sent using Flows in SFDC and pull those into MadKudu for use. (Process Time: 4-6 hours)...

  4. Run the exported values from the aggregations in 1 and 2 back into MadKudu and run Super-Aggregations (or simply do that math outside in SFDC using a formula field). (Process Time: 4-6 hours)...

  5. Run computations for Content Decision. (Process Time: 4-6 hours)... Total of 12 to 18 hours total for full sequence to update and run.

This process leverages MadKudu as part of the larger Ops stack and yes, requires one to be reasonably familiar with ops, the CRM and the modern data stack, have flexibility in field creation and storage outside of MadKudu leveraging these various platforms, and also just be pretty damn organized with their content and campaign hierarchy.

That all being said, it does provide functionality that is difficult to set up, monitor and manage in most MAPs or Sales Enablement platforms. Not to worry, if all content is exhausted, the logic should hold across your MAP or Sales Enablement platform to avoid re-sending any content already provided. Of course, with the new processes you would have in place after implementing the above, you’ll be able to call on Growth, Product, and DemandGen teams to create plenty more long before you run out!

Need more Technical Documentation?

Head over to our Zendesk and find information regarding integrations, scoring details, and more.

View Documentation

Want In-Person Support?

If you would like more personalized assistance - feel free to schedule a call with our product team.

Schedule a Call