Skip navigation
All Places > Champion Program > Blog > 2016 > August
2016

Watch Episode 4 here: #KreweChats Episode 4: What is Nurture Marketing? - YouTube

 


 

Another great episode of #KreweChats in the books!  Our topic this week was Nurture Marketing, what it is, how to think about it towards prospects and clients, as well as some strategies. Guest chatter Brent Levi joined some of the usual characters, Jenn DiMaria, Juli James, Joe Reitz and me.

 

Nurture Marketing goes way beyond simple drip-nurture marketing.  In this episode we expose the mktgnation to broader concepts and ideas to help in Nurture Marketing your efforts.

 

Topics we covered in this episode:

  • FUN FACT: Our first cars
  • What is Nurture Marketing
  • How to make messaging relevant and personalized
  • Data points to gather and actions based on them
  • Sales team adoption and reaction to Nurture Marketing
  • Alignment with the overall sales process: Full Funnel approach
  • Nurture models: pre-customer / post-customer, full lifecycle model
  • Brand voice as part of Nurture Marketing

 

 

Tune in for our next episode in another two weeks on September 9 at 3:30 ET / 12:30 PT.

 

 

Also....

 

Check out past episodes of #KreweChats

#KreweChats Week 3: Lead Scoring and MSI

Krewe Chats Week 2: Data Management

Krewe Chats: Episode 1 - How to Get the Most Value out of Community

 

 

We're here to serve the Community.

 

Let us know what topics you would like to see covered in an upcoming episode!

Please leave us comments or feedback below!

 

Thanks again for watching!

If you spend long enough building in Marketo, you will very likely encounter scenarios where things don’t happen they way you’d expect.

 

You may have two different smart campaigns - which are in themselves perfectly functional - produce a bad result because they didn’t execute in the right order.

 

I would say 90% of the issues I’ve had in Marketo have been some variant on this simple theme of order of operations.

 

Order of operations is often the difference between a stable, predictable, and effective Marketo instance and a disorderly chaotic mess. If you aren’t constantly thinking about and controlling the order that things happen, your Marketo systems will eventually break, no matter how much cool stuff you build.

 

Do you have a race condition?

(You may want to ask your doctor...)

 

A race condition is when a successful outcome of a process (e..g, a smart campaign) is dependent upon some other process being completed first, but those processes occur asynchronously and in an uncontrolled way.

 

When the processes don’t occur in the right order, then the dependant process fails.

 

Symptoms of a race condition include:

 

  • Leads being misrouted in your CRM because they were synced before key data values were written to the lead record.
  • Alerts being sent to no one because they fired before a sales owner was assigned.
  • Lead Lifecycle Stages getting overwritten because a lead qualified for multiple lifecycle campaigns at the same time.
  • People in your office talk about how “Marketo is broken”.
  • Your life as a Marketo Admin becomes like:

 

01 More Dupes.jpg

(This actually happened to me.)

 

Fortunately, race conditions are both preventable and treatable. Here’s how.


Tactics for Controlling Order of Operations

The list of tactics below isn’t definitive, but it covers the most obvious ways to control order of operations and the ones I’ve found to be most useful.

 

All these methods need to be used within a well-designed system in order to work well, but that’s a subject for another post.

 

1) Keep Your Actions in a Single Smart Campaign

The simplest way to control the order of a series of flow steps is to keep them all in a single smart campaign.

 

Pros

  • Simple and effective.
  • Order of operations for flow steps in a single smart campaign is basically guaranteed. A lead moves from one flow step to another in sequence.

 

Cons

  • This approach is suited only for very simple scenarios, with a few actions that always go together in a linear sequence. Once you introduce multiple conditions and more advanced logic, this approach breaks down.
  • Long lists of flow steps that do lots of different things are hard to understand.

 

When to Use

If you have a few simple activities you are trying to chain together in a straightforward linear flow, this method works great.

 

Example: Form Auto-Responder

When a lead fills out a form, you want to add the lead to a Salesforce campaign, send the lead a thank-you email, and then send an alert to distribution list. All these steps happen in quick sequence and have no other dependencies outside the campaign. So based on these requirements, a single smart campaign works very well.

 

Eg 1 - Single Campaign - Smart List.jpg

 

Eg 1 - Single Campaign - Flow.jpg

 

2) Wait Step

A wait step allows you to pause your lead in a flow for a designated period of time before doing something else. While your flow is waiting, it gives a chance for other stuff to happen elsewhere in your system.

 

Wait steps are the most commonly used (and misused) method for controlling order of operations that I’ve seen.

 

Unfortunately, wait steps are still basically just guesses. A wait step waits however long you tell it to, and has no awareness of what you might be waiting for. Systems are unpredictable - depending on conditions, your wait step might be too long or too short.

 

Pros

  • Wait steps are simple and easy to understand.
  • Wait steps are precise when all you want is to pause a process for a specific period of time, irrespective of what else might be happening in the system.

 

Cons

  • If your other process is not specifically time-bound, there is no guarantee that the wait step will be long enough. It’s better than nothing, but definitely not bulletproof.
  • If a wait step proves too short, people tend to make them longer and longer to provide more security. Unfortunately, this means that your process gets slowed down to the lowest common denominator and you lose velocity the rest of the time.
  • Campaigns with wait steps are deprioritized in the campaign queue.

 

When to Use

Wait steps are generally not a robust method for coordinating asynchronous processes with no clearly defined time interval.

 

This doesn’t mean never use them in these scenarios (sometimes the complexity of doing otherwise is impractical). However I would make them my last resort.

 

To my mind, there is really just one scenario where a wait step is always a suitable option: when you want your process to wait for a defined period of time (no matter what else is happening).

 

Example: Free Trial Emails

A lead initiates a free trial of a product. Your campaign sends a welcome email, then waits 30 days while the lead tries out the product. At the end of the 30 day period, the flow checks if the lead has upgraded their trial, and if not, sends an upgrade offer.

 

In this case, a wait step works just fine because we know the trial is exactly 30 days and we are checking their current state after 30 days before sending the next message.

 

Eg 2 - Wait Step - Smart List.jpg

 

Eg 2 - Wait Step - Flow.jpg

 

3) Request Campaign

The Request Campaign flow step (and its companion, the Campaign Is Requested trigger) are oddly polarizing in our community. I find this feature inspires either passionate enthusiasm or antagonism among Marketo users, depending on who you ask.

 

I’m a fan of Request Campaign. I find it the most direct and logical way of having one campaign trigger another. It provides enormous flexibility in how you structure your campaigns and makes it very easy to route people through operational programs multiple times.

 

On the flip side, you have many people state that this trigger can slow down your Marketo instance.

 

Now, I haven’t seen any hard and fast evidence or official statement that the Campaign Is Requested trigger requires more processing time than any other trigger on a one-for-one basis. To be honest, I suspect that part of the issue is that Request Campaign can lead to more “trigger-happy” design patterns, causing an overall increase in the volume of trigger campaigns. And that definitely can decrease overall performance, regardless of the trigger you use.

 

However, even assuming it is a bit more resource intensive, it doesn’t mean we can’t use this trigger; in some scenarios, it is still the most efficient tool for the job considering all the factors involved.

 

The main thing is to use it judiciously, which is a rule to apply to all trigger campaigns in general.

 

Pros

  • Request campaign is a very logical and bulletproof way to ensure one campaign triggers another.
  • Flexible and extensible for a wide variety of situations.
  • Quick and easy to deploy for ad-hoc use.
  • Allows for centralization of repeatedly used functions, which is easier to maintain.
  • No limit on how often a campaign can be requested for any one lead.

 

Cons

  • Potential performance impact at higher scale.
  • Some people find it harder to work with and troubleshoot.

 

When to Use

I use Request Campaign in scenarios where I need one campaign to immediately trigger another and other methods are too clunky. I think it’s especially suitable where you have a central operational campaign that you need to repeatedly trigger from a wide variety of places -- i.e. a high ratio of flow steps requesting a single trigger.

 

Example: Centralized MQL Processing

You have a series of multiple flow actions that need to happen when someone fills out a fast track form, all of which terminate in a sync to Salesforce. You need to ensure that the Salesforce sync happens only once all the previous flow actions are complete.

 

Furthermore, your demand gen team is super form-happy, and you have over 100 unique form placements to deal with.

 

You could recreate those flow steps 100 times in each form program followed by 100 “Sync to SFDC” flow steps, but this is brutal to maintain if anything changes and makes it impossible to coordinate your sync with other processes.

 

Instead, create a single MQL processing campaign in your lifecycle program that includes a sync flow step. Now you can now request it from anywhere you want, maintain one version of the process, and control when and how someone enters that flow.

 

This uses only one Campaign Is Requested trigger and ensures that your process works even if a lead fills out the same form multiple times.

 

Eg 3 - Request Campaign - Smart List.jpg

 

Eg 3 - Request Campaign - Flow.jpg

 

4) Static Lists

Static lists can be used in almost the exact same way as Request Campaign. Instead of a Request Campaign flow step, use an Add to List flow step. Instead of a Campaign Is Requested Trigger, use the Added to List trigger.

 

There are some benefits to doing it this way. Static lists can be deployed quickly and in an ad-hoc way and disposed of just as easily. Lists also provide some additional insight that can be used in your operational reporting, since the list keeps a running count of people who have passed through the process.

 

The main drawback is you can only be added to a static list once. If you use the fast-track form example above, what happens the second or third time someone fills out the same fast track form?

 

To make sure your process doesn’t break, you would need to ensure you have additional automation to remove the lead from the static list when the process is complete. This is extra overhead and it creates the possibility for error (plus sets you up for more potential race conditions).

 

Pros

  • Allows one campaign to trigger another another.
  • Flexible for a wide variety of situations and very extensible (no functional limit to the number of static lists you can create).
  • Quick and easy to deploy for ad-hoc use.
  • Allows for centralization of repeatedly used functions, which is easier to maintain.

 

Cons

  • Managing 5 bazillion static lists.
  • For repeated processes, additional automation is required to remove leads from the static list after a process is complete. This creates the potential for failure if a lead isn’t removed correctly or not removed quickly enough.

 

When to Use

Static lists are a very sensible choice in most scenarios you might encounter, as long as there is no concern around being able to successfully remove the lead from the list in time.

 

I find static lists especially valuable when you need to identify a subset of leads that are waiting for a particular process to end, usually triggered by a data value change. The static list membership becomes a filter on a campaign triggered by that data value change, allowing you to control when those leads move through the flow.

 

Example: Send Alert After Owner Is Assigned

When someone fills out a fast-track form, you want to send an alert to the owner if the record has an owner in your CRM (we’ll use Salesforce for this example). However, at the moment the lead fills out your form, they may OR may not already have an owner assigned.

 

If they do have an owner assigned, your campaign should send the alert to that person. If the owner is not yet assigned, you need to wait until the owner is assigned (an outcome controlled by another process in another system) and then send the alert.

 

Campaign #1

The first campaign checks if the lead has an owner; if it does, the alert is sent, and if not the person is added to a static list to identify them as someone waiting for an owner.

 

Eg 4a - Static List - Smart List.jpg

 

Eg 4a - Static List - Flow.jpg

 

Campaign #2

The second campaign listens for lead owners changing BUT uses the static list membership as a filter. The list allows you to precisely identify the leads you want to take action on once their owner changes.

 

Eg 4b - Static List - Smart List.jpg

 

Eg 4b - Static List - Flow.jpg

 

5) Program Statuses

Program statuses are another very flexible method for controlling order of operations. The flow step is Change Program Status and the corresponding trigger is Program Status Is Changed. You can also use the “Member of Program” filter with specified program statuses.

 

Program statuses can be especially elegant when you are trying to coordinate a multi-stage operational process, since the various stages of your process can map against the statuses of a program channel. (My colleague Kristen did a Summit session all about this method, with some useful examples.)

 

For operational channels, make sure to exclude them from reporting and keep all your program statuses at the same number. That way, when a process is complete, you can easily move someone back to the first status if you want them to move through the process multiple times.

 

Pros

  • Allows one campaign to trigger another another.
  • Flexible for a wide variety of situations.
  • Allows for centralization of repeatedly used functions, which is easier to maintain.
  • Can be used repeatedly for the same lead if set up correctly.
  • Provides a quick “at-a-glance” view of how many leads sit where in your process
  • Program status changes are logged permanently in the activity log and do not get archived.

 

Cons

  • Less quick and easy to deploy - requires admin access to create new channels.
  • Potentially less extensible than other options.
  • Difficult to modify program statuses once existing programs are using them - plan your processes carefully.

 

When to Use

Program statuses would be my preferred option for operational programs where you have a clear multi-stage process that forms the foundation of your system. It is also an excellent choice for marketing activities that occur consistently in the same way.

 

For one-off or ad-hoc usage, a static list is a better choice as you don’t need to commit to creating a new channel in the admin.

 

Example: Lead Scoring Threshold

You have a single operational program set up to score your leads. Your scoring program has a defined score threshold. Leads reaching the threshold should be transitioned to MQL.

 

Additionally, your program needs to allow leads to be recycled, at which point there is a holding period where they are not eligible to reach MQL status again. After the holding period, their behavior score is reset to zero and they can reach MQL again.

 

Program Channel

 

Eg 5 - Program Statuses - Channel.jpg

 

Program

The scoring flows would go in their appropriate folders, while the two campaigns below live in a “Management” folder.

 

Eg 5 - Program Statuses - Program.jpg

 

Campaign #1

When the lead reaches your scoring threshold, change their program status to “Reached Threshold”. This should serve to activate a trigger in a central lead lifecycle processing campaign (like the MQL flow above), which will handle everything associated with routing the lead to MQL.

 

Additionally the other program statuses serve as a filter to ensure that leads who have already reached a threshold or are in purgatory after being recycled do not get re-processed.

 

Eg 5a - Program Statuses - Smart List.jpg

 

Eg 5a - Program Statuses - Flow.jpg

 

Campaign #2

The second campaign triggers once the lifecycle stage changes to recycled. The lead is moved into a waiting program status for the appropriate period (30 days in this example). After the wait, the scores are reset and the program status changes again.

 

Eg 5b - Program Statuses - Smart List.jpg

 

Eg 5b - Program Statuses - Flow.jpg

 

In this case, the program statuses serve to trigger a process in another program and control the flow of leads within this program. Another benefit of this structure is that you can see at a glance from the program summary view how many leads you have in each stage.

 

Eg 5c - Program Statuses - Program Summary.jpg

 

6) Data Value Changes

If you are orchestrating processes that involve updates to lead data, data value changes are a very natural way to connect them.

 

There are many possible use cases here; the send-alert-after-owner-change example above is also a good example of a process triggered by a data value change, since the Salesforce process of assigning an owner triggers the alert in Marketo when the owner value updates.

 

There are a few restrictions here - most obviously, a field must exist in your schema in order to trigger off a change to it. For ad hoc use where a field isn’t already involved, it would be better to use another method, such as adding someone to a static list.

 

Pros

  • Allows one campaign to trigger another another.
  • Allows you to leverage existing data updates to control order of operations without any additional build or campaign overhead.

 

Cons

  • Requires a data field to exist in your schema.
  • For repeated processes, additional automation is required to reset a data value after a process is complete. This creates the potential for failure if the field isn’t updated correctly or quickly enough.
  • Data value changes are archived after 90 days, making this more difficult to audit over time.

 

When to Use

If a process is already updating a data value, and this update indicates that other processes can start, then using this as a trigger is a smart idea. Lifecycle stage updates, score changes, a lead source being set, and so on.

 

Example: Data Enrichment for Lead Routing

You and your SFDC admin want to team up to create some automated lead assignment rules. To route leads properly, you need some key data values to be populated - and you don’t want to kill your form conversion by adding a bunch of new fields.

 

Enter a new data enrichment vendor, who provides you with a webhook that you call in Marketo when the lead is created to enrich them with data like company size, headquarters location, and industry.

 

Your SFDC Admin sets up assignment rules so that when the leads sync to Salesforce they will get sent automatically to the right reps based on the enriched data. Huzzah!

 

However, at first you run into some problems. Both your data enrichment webhook and your lifecycle flow for new leads trigger off of “lead is created.” You need to find a way to make sure that the leads are not sent to Salesforce until the data enrichment webhook has finished pushing in data. This can happen almost instantly or take 1-2 minutes depending on how the enrichment vendor’s API is behaving.

 

The answer is to chain these actions together using a data value change.

 

Campaign #1

Your data enrichment process actually becomes the first step in your lifecycle processing, because it needs to be complete before you take any other action. So when the lead is created, you call your webhook.

 

Eg 6a - Data Value - Smart List.jpg

 

Eg 6a - Data Value - Flow.jpg

 

Campaign #2

In the webhook response containing the enriched data, your vendor will also pass back a status code. You can map this value into a field and use it to trigger the next step of your process.

 

Eg 6b - Data Value - Smart List.jpg

 

Eg 6b - Data Value - Flow.jpg

 

Of course this is an oversimplified example and in real life there are other things to consider. For example, if your enrichment webhook fails for any reason, you need a backup to ensure the lead is still processed. But you can see how this method is a lot more bulletproof than a wait step. You are essentially guaranteeing that your sync is not going to happen until the enrichment is complete.

 

Wrapping Up

Obviously there are about 5 different ways of executing any of the examples I mentioned above. Those ways aren’t all created equal, but there’s room for reasonable people to prefer different methods for various reasons. That level of flexibility and freedom is part of what makes Marketo great.

 

I’m really interested in what other people are doing in the trenches day to day, so please share your agreements, your disagreements, and your favorite methods I didn’t mention below.

Originally Posted by Sanford Whiteman in New York User Group on Aug 16, 2016 7:17:30 PM

 

As a precursor to a longer series of Velocity posts, let's look at data types in the scripting environment vs. in the Marketo database. The rule (singular) is simple: in my tests every lead field is exported as a string into Velocity, regardless of whether it's a Boolean, Date, Number, Score, DateTime, or String type within Field Management and the individual Lead UI.

Read the full post on TEKNKL :: Blog →

This post is about how reports/analyzers & smart lists filter "Lead Created" differently.

[I wanted to write this post because I had a hard time figuring out why my reports were showing different results according to the "lead created" filter. So, I figured just having an explanation in the Marketo-sphere could help someone, sometime.]

 

If you need to pull a report within a specific time period your setup will most likely contain "Lead Created at" in the setup tab:

 

 

 

If you pull the report without adjusting the smart list, your results will not reflect the existing numbers in your database (especially if your database is always deduping leads, cleaning invalid emails, etc.). The reason for this is because reports/analyzers will display data for leads that were created but have since been deleted/merged.

 

In order to filter out all of the deleted/merged lead numbers in the report, you will need to add the “lead created” filter in the smart list.  The reason this will work is because this smart list field populates results that are existing, known leads.

 

 

Also, if you make any changes to records in your database it can take up to 24 hours for the reports/analyzers to update with that new information.

 

Cheers,

Ande

Hi All, and welcome to the third episode of #KreweChats! Last Friday, Dory Viscogliosi, Sydney Mulligan, Joe Reitz (kinda) and I chatted about the basics of lead scoring, implementing and maintaining Marketo Sales Insight (MSI) and touched briefly on alerts before realizing that should probably be a topic in and of itself.

 

If you missed the live-stream on Friday (or even if you didn't!) you can (re)watch here: #KreweChats Episode 3: Lead Scoring, Alerts and Marketo Sales Insight

 

Here's what we covered:

  • Lead scoring
    • What is the purpose?
    • What should you score? (Probably not email opens... they are pretty unreliable!)
    • How can you set it up? How do you decide what's important to score?
    • Balancing lead scores between Demographic and Behavioral
    • Lead scoring is not one size fits all! Just because it works for one company, doesn't mean an identical setup will work for another
    • KISS Tokenized Lead Scoring (Keep It Simple Stupid!)
  • MSI
    • Getting Sales on board with MSI and making them love it
    • Logging MSI email sends as an SFDC activity (vote for Sydney's idea here!)
    • Has MSI helped the relationship with Sales?
    • DON'T BE CREEPY!

 

The next episode will be on August 26 at 3:30 ET / 12:30 PT. You can view it live here. And, of course, we will be Tweeting about it.

 

***

Also, as promised, here are a couple screen shots of our tokenized scoring after we had our Marketo instance set up last year and I realized that the colleague who set up our scoring program didn't fully understand the purpose of tokens. **sigh**

 

Here is the old setup. As you can see, there are various "Downloads" activities that have "+10" as the value. Because we can use Tokens in more than one location throughout our campaigns, we can combine all of those values into one token.

Scoring-Tokens_Old.png

 

When I reorganized our scoring, I simplified the tokens. We have a High, Medium and Low value for each activity type and that allowed us to reduce the total number of lead score tokens from 63+ to about 25. Much more manageable! (As you can see, the 9 downloads tokens we had set up originally were decreased to 3 below).

Scoring-Tokens_New.png

How do you maintain the intelligence of a field like Comments or Description that keeps getting overwrittten?

 

For example, let’s say you get in this new trade show list with a Comments field filled values like “Hot lead at Miami event, has budget and wants demo.” Later on, one of those folks fills out your Contact Us form with a Comments value of “I spoke w your rep Ken at the show and need pricing.”

 

The problem is that every time the Comments field is populated, it overwrites the previous value, thus losing intelligence for the Sales team. In other instances, these values are maintained in different fields causing an ongoing data management nightmare.

CommentsDemo.jpg

The Solution---Merge the Data. To summarize, this solution involves creating a field that temporarily stores the latest comments information. Every time that value is updated, it will prepend the Comments field with the new data.

 

The end result is a Comments field that is continually updated while maintaining historic intelligence. This process allows Sales and Marketing to easily view ongoing comments from multiple marketing initiatives.

 

Let’s Dive in with a 4-Step Process

Follow this approach for concatenating the Comments field.

 

Step 1 - Standardize on a single field for comments collection across forms, imports etc. Use Description, Comments or whatever other field syncs between your Marketo and your Salesforce Lead/Contact objects. I’ve seen different companies use all kinds of varying fields to collect data like comments or descriptions. As a recommendation, choose one and standardize.

 

Step 2 - Create a matching field called something like Comments Temp. Feel free to make this a Marketo only field as its only purpose is to temporarily capture the latest comments.

 

Step 3. Leverage all the new Comments Temp field across all appropriate forms. Also, when you get in data from trade shows, make sure to use the Comments Temp field upon import for the appropriate field. You do NOT want to use the standard Comments field as you will overwrite that data. Commentsa.jpg

 

Step 4. Create a data updating campaign that makes all the magic happen.

 

When: The campaign fires upon any of the updates you made in step 3--for example, when a new lead is created and the Comments Temp field is populated. It also fires when there is a change in value to the Comments Temp field.

CommentsSmartList.jpg

 

The Flow: This is the special sauce that leverages tokens to populate the values the way you want. In this example, the current date and Comments Temp values will get prepended to existing value in the Comments field.

CommentsSmartFlow.jpg

 

You may also elect to nullify the value in the Comments Temp after 20 or so minutes in the event you use that field for alerts or other workflows.

The Final Product - Ongoing Intelligence

This Comments field will grow with ongoing intelligence every time the Comments Temp field is updated.  The process will keep a running history of your intelligence for your Sales team to view. Let's look at the below examples.

 

CommentsSalesforce.jpg

 

The Comments field is populated on 10/1/2016 when the lead is created from a trade show import.[/caption]

CommentsSalesforce1.jpg

Here, the Comments field is prepended with new information after the person fills out a Contact Us form. The previous intelligence is maintained instead of overwritten.

 

Other Alternatives to Field Merging

An acceptable alternative is to log an Interesting Moment using the Comments Temp values. The issue here is the interesting moment might be too long to read in Salesforce. However, you might want to try that out.

 

An unrecommended approach is to create comment fields for various marketing initiatives (EventA Comments, EvalRequest Comments, etc.). This strategy doesn’t scale too well and creates extra fields to manage. Salesforce Administrators generally put marketers who want too many fields in the doghouse so I recommend avoiding this process if possible.

 

How are you Merging Data?

 

I hope you've seen the power of concatenating data to keep an ongoing record of your Comments field--it's also pretty easy to set up. Concatenating provides a lot of flexibility for marketers to enhance intelligence. The above is just one of many examples. I’d love to hear how others are experiencing success with this method. Please share below in the Comments.

 

A few other examples we've seen leveraging the data merging method.

  • Bring together the latest activity and date: Latest Activity = {{lead.lead source details}} on {{system.date}}
    • Example: Google Web Referral on January 12, 2017
  • Enrich the Lead Source with UTM values: Lead Source = {{lead.utm_source}} via {{lead.utm_medium}} for {{lead.utm_content}}
    • Example: Search engine via CPC for Spring Sale
  • Create Name: Full Name = {{lead.firstname}} {{lead.lastname}}
    • Example: Jon Scott
  • Enrich Lead Source Details with Referral info = Web via {{lead.original referer}}

More information in the Marketo docs.

A similar version is posted on the RevEngine Insider blog.