Connect with us

SEO

Do Manual Adjustments Still Make Sense With Automated Bidding?

Published

on

How Can I Build On SEO Knowledge To Be Better In PPC?


Every ad platform has some degree of automated bidding.

The decision to lean into giving ad platforms control over bids has gone from a hard no to “it depends.”

When implemented correctly, automated bidding can outperform human governed bids.

Goals that don’t align with the budget can doom automated bidding.

Additionally, automated bidding will block some settings from influencing the campaign.

So it makes sense that Caterina from Oslo wants to know:

“Does it still make sense to adjust locations, time, segments, and device bid with Google’s automated bidding strategies?”

In this installment of Ask the PPC, we’ll go over:

Advertisement
  • The difference between manual, smart, and automated bidding.
  • Which bidding strategies allow for manual adjustments.
  • When it makes sense to go manual vs. automated.

What’s The Difference Between Manual, Smart & Automated Bidding?

Manual bidding is the most straightforward: The advertiser sets the bid and uses bid adjustments to direct budget toward or away from people, places, times, and devices.

Advertisers can choose to use scripts to automate manual bidding, so it’s closer to the real-time bidding found in automated/smart bidding.

Smart bidding focuses on a “smart” goal like conversions or return on ad spend (ROAS).

These bidding strategies only allow advertisers to adjust the budget and the goal parameters (target cost per acquisition and ROAS).

While you can still adjust some settings, they will not focus budget toward or away from people, places, times, and devices.

Automated bidding focuses on all other goals, such as target impression share and clicks.

These bidding strategies allow advertisers to adjust budgets and add bid caps.

Other than that, they have the same manual adjustment limitations as Smart bidding.

Which Bidding Strategies Allow For Manual Adjustments?

It can be tough to track exactly which adjustments are possible for all bidding strategies.

Advertisement

Here is a breakdown of what each does:

Manual (ecpc)

  • Positive Bid Adjustments (increases bid): device, location, audiences, and schedule.
  • Partial Negative Bid Adjustment (lowers bid): device, location, audiences, and schedule.
  • Full Negative Bid Adjustment (exclusion): device, location, audiences, and schedule.

Maximize Clicks

  • Positive Bid Adjustments: none.
  • Partial Negative Bid Adjustment: none.
  • Full Negative Bid Adjustment (exclusion): device, location, audiences, and schedule.

Target Impression Share

  • Positive Bid Adjustments: none.
  • Partial Negative Bid Adjustment: none.
  • Full Negative Bid Adjustment (exclusion): device, location, audiences, and schedule.

Maximize Conversion Value

  • Positive Bid Adjustments: none.
  • Partial Negative Bid Adjustment: none.
  • Full Negative Bid Adjustment (exclusion): device, location, audiences, and schedule.

Maximize Conversions

  • Positive Bid Adjustments: device, location, audiences, and schedule will allow for a higher Target CPA goal.
  • Partial Negative Bid Adjustment: device, location, audiences, and schedule will allow for a lower Target CPA goal.
  • Full Negative Bid Adjustment (exclusion): device, location, audiences, and schedule.

When It Makes Sense To Go Manual vs. Automated

Budget is the biggest deciding factor for manual vs. automated bid adjustments/bidding strategies.

It’s critical that automated systems have enough data to fuel machine learning.

If the budget is constrained, you will need to go manual to force the budget to spend.

If you go manual, it’s ideal to keep the bids conservative and go aggressive on the bid adjustments.

For example, if the auction price ranges from $5 to $17, bid closer to the bottom range and use 50% to 75% bid adjustments.

Scripting bid adjustments can make sense if you have a larger account and/or you need to make real-time adjustments.

Fully automated (i.e., using bid strategies) can make sense if you have a reasonable budget for your industry.

The goal is to get here and use the adjustment categories as exclusions only.

Advertisement

Have a question about PPC? Submit via this form or tweet me @navahf with the #AskPPC hashtag. See you next month!

More resources:


Featured Image: Paulo Bobita/Search Engine Journal

fbq('trackSingle', '1321385257908563', 'ViewContent', { content_name: 'manual-adjustments-vs-automated-bidding', content_category: 'ask-ppc ' });





Source link

SEO

WordPress Considers Historic Development Change

Published

on

WordPress Considers Historic Development Change

Matt Mullenweg, developer of WordPress and CEO of Autommatic, proposed no longer adding new features to the WordPress, pivoting instead to a plugin-first policy.

This new approach to the future of WordPress has already resulted in a new feature intended for the next version of WordPress to be dropped entirely.

Canonical plugins are said to offer a way to keep improving WordPress on a faster schedule.

But some WordPress core contributors expressed the opinion that publisher user experience may suffer.

Canonical Plugins

First discussed in 2009, canonical plugins is a way to develop new features in the form of plugins.

The goal of this approach is to keep the WordPress core fast and lean while also encouraging development of experimental features in the form of plugins.

The original 2009 proposal described it like this:

“Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.

…There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility.”

Advertisement

This approach to features and options is also referred to as Plugin First, to emphasize how features will first appear in the form of plugins.

These plugins are called canonical because they are developed by the WordPress core development team as opposed to non-canonical plugins that are created by third parties that might limit features in order to encourage purchase of a pro-version.

Integration of canonical plugins into the WordPress core itself would be considered once the plugin technology has proven itself to be popular and essential to the majority of users.

The benefit of this new approach to WordPress would be to avoid adding new features that might not be needed by the majority of users.

Plugin-first could be seen to be in keeping with the WordPress philosophy called Decisions, Not Options, which seeks to avoid burdening users with layers of technical options.

By offloading different features and functionalities to plugins, a user won’t have to wade through enabling or disabling functionalities they need, don’t need or don’t understand.

The WordPress design philosophy states:

“It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.”

Canonical Plugins the Future?

Matt Mullenweg published a post titled, Canonical Plugins Revisited, in which he made the case that this is the way that WordPress should be developed moving forward.

Advertisement

He wrote:

“We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and and path to come into core if the plugin becomes a runaway success.”

The first casualty of this new approach is the cancellation of integrating WebP image conversion into the next version of WordPress, WordPress 6.1, currently scheduled for November 2022.

Plugin-First is Controversial

The shift to a plugin-first development process was subjected to debate in the comments section.

Some developers, such as core contributor Jon Brown, expressed reservations about the proposal to switch to developing with canonical plugins.

They commented:

“The problem remains that there are too many complicated plugins standing in for what would be a simple optional feature.

Plugins are _not_ a user-friendly option to core settings. First users have to discover there is a plugin, then they have negotiated yet another settings screen and updates and maintenance of that plugin.”

The commenter used the example of a commenting functionality that is currently served by mutliple bloated plugins as a less than ideal user experience.

They noted that having one canonical plugin to solve a problem is preferable to the current state where desirable options can only be found on bloated third party plugins.

Advertisement

But they also said that having a settings option within core, without the need for a plugin, could present a better user experience.

They continued:

“Now, I do think Canonical plugins are a better situation than 6+ bloated plugins like exist here, but so would a single checkbox added to the settings page in core to do this. Which would further improve the UX and discovery issues inherent in plugins.”

Ultimately, the commenter expressed the idea that the concept of canonical plugins seemed like a way to shut down discussions about features that should be considered, so that the conversation never happens.

“Canonical plugins” seems like a weaponized tool to derail discussions the same way “decisions not options” has become for years.”

That last statement is a reference to frustrations felt by some core contributors with the inability to add options for features because of the “decisions, not options” philosophy.

Others also disagreed with the plugin-first approach:

“Canonical plugin sounds grand but it will further increase maintenance burden on maintainers.

In my opinion, it’s no go.

It will be much more better to include some basic features in core itself instead of further saying – It’s a good place for plugin.”

Someone else pointed out a flaw in plugin-first in that collecting user feedback might not be easy. If that’s the case then there might not be a good way to improve plugins in a way that meets user needs if those needs are unknown.

Advertisement

They wrote:

“How can we better capture feedback from users?

Unless site owners are knowledgeable enough to report issues on GitHub or Trac (let’s be honest, no one reports plugin issues on Trac), there’s really no way to gather feedback from users to improve these recommended/official plugins. “

Canonical Plugins

WordPress development is evolving to make improvements faster. Core contributor comments indicate that there are many unresolved questions on how well this system will work for users.

An early indicator will be in what happens with the cancelled WebP feature that was previously intended to be integrated into the core and will now become a plugin.


Featured image by Shutterstock/Studio Romantic

Source link

Continue Reading

DON'T MISS ANY IMPORTANT NEWS!
Subscribe To our Newsletter
We promise not to spam you. Unsubscribe at any time.
Invalid email address

Trending

en_USEnglish