Local Services campaigns

Local Services campaigns let you advertise your business on Google and receive leads directly from potential customers. This guide summarizes the supported operations and restrictions in the current version of the Google Ads API.

Supported operations

Retrieve Local Services campaigns and budgets

Local Services campaigns and budgets can be retrieved using the GoogleAdsService.Search or GoogleAdsService.SearchStream method to query for the campaign resources where advertising_channel_type = 'LOCAL_SERVICES'. Here is an example:

SELECT
  campaign.id,
  campaign.status,
  campaign_budget.id,
  campaign_budget.period,
  campaign_budget.amount_micros,
  campaign_budget.type
FROM campaign
WHERE campaign.advertising_channel_type = 'LOCAL_SERVICES'

Edit Local Services campaigns

You can update the campaign's status and the associated campaign budget's amount_micros fields.

Set the bidding strategy of Local Services campaigns

You can set the following bidding strategies as the standard bidding strategy of Local Services campaigns:

Set an ad schedule as a campaign criterion

You can set an ad schedule for a Local Services campaign as a campaign criterion.

Create an AdScheduleInfo and set it to the ad_schedule of the CampaignCriterion that is sent to the Google Ads API, using CampaignCriterionService.MutateCampaignCriteria.

Set location targeting

To enable location targeting for a Local Services campaign, add a LocationInfo and set it to the location of the CampaignCriterion that is sent to the Google Ads API, using CampaignCriterionService.MutateCampaignCriteria. For more details, see Location targeting.

Target specific service types

To enable targeting for a specific service type, add a LocalServiceIdInfo and set it to the type of service.

You should use a service ID that matches your campaign's targeting location and category.

Unsupported operations

The restrictions listed in the following table can change in future versions of the Google Ads API.

Unsupported operations
Create and remove campaigns The Google Ads API blocks creation of new Local Services campaigns.
Operations on sub-entities in a campaign The Google Ads API does not support the creation, modification, removal, or retrieval of ad groups, ads, or criteria in Local Services campaigns.

Local Services resources

Starting in Google Ads API v15, some data from Local Services Ads are exposed directly in the Google Ads API through the following read-only report resources:

In order for these resources to return data, there must be a Local Services campaign in the client account making the request. And since there can only be one Local Services campaign per client account, these resources don't specify a campaign. To identify the campaign that these resources are affiliated with, use the following query:

SELECT campaign.id
FROM campaign
WHERE campaign.advertising_channel_type = 'LOCAL_SERVICES'

Local Services lead

LocalServicesLead exposes the details of a lead that are generated when a consumer calls, messages, or books a service from the advertiser.

Local Services lead data can be retrieved from the local_services_lead resource. Here's an example query:

SELECT
  local_services_lead.lead_type,
  local_services_lead.category_id,
  local_services_lead.service_id,
  local_services_lead.contact_details,
  local_services_lead.lead_status,
  local_services_lead.creation_date_time,
  local_services_lead.locale,
  local_services_lead.lead_charged
FROM local_services_lead

Limitations

  • The contact_details field is null if lead_status equals WIPED_OUT.
  • Data from leads where the category_id is part of a healthcare category are not available.

Local Services lead conversation

LocalServicesLeadConversation exposes the details of conversations that have taken place as part of a LocalServicesLead. There is a one-to-many relationship with LocalServicesLead, where one lead can have many conversations. The resource name for the related lead can be found in the lead field.

Conversation data can be retrieved from the local_services_lead_conversation resource. Here's an example query that filters for results that are phone calls:

SELECT
  local_services_lead_conversation.id,
  local_services_lead_conversation.conversation_channel,
  local_services_lead_conversation.participant_type,
  local_services_lead_conversation.lead,
  local_services_lead_conversation.event_date_time,
  local_services_lead_conversation.phone_call_details.call_duration_millis,
  local_services_lead_conversation.phone_call_details.call_recording_url,
  local_services_lead_conversation.message_details.text
FROM local_services_lead_conversation
WHERE local_services_lead_conversation.conversation_channel = 'PHONE_CALL'

Limitations

  • To access the call recording URL, you must sign in with an email address that has at least read-only access to the Google Ads client account that owns the campaign that the lead is associated with.

  • Requesting all conversations at once can be a time-consuming request, so you should filter conversations by lead, for example:

    SELECT
  local_services_lead_conversation.id,
  local_services_lead_conversation.event_date_time,
  local_services_lead_conversation.message_details.text
FROM local_services_lead_conversation
WHERE local_services_lead.id = LEAD_ID

Local Services verification artifact

LocalServicesVerificationArtifact exposes verification data for advertisers' businesses. Note that these verifications are at the business level and don't include verifications for employees. The data includes the following:

  • License verifications
  • Insurance verifications
  • Background check verifications

Any time a verification request is submitted to Local Services Ads, a new verification artifact instance is created for it in the Google Ads API, and each verification artifact represents a single verification request. Each verification artifact might contain some of the following information, depending on what type of verification request it represents:

  • Status of each verification artifact
  • Background check URL to be used for background check verification
  • Background check adjudication time (if applicable)
  • Insurance document URL to view the already-submitted Insurance information
  • Insurance rejection reason (if applicable)
  • License details (type, number, first, last names)
  • License rejection reason (if applicable)
  • License document URL to view already submitted license image (if applicable)

Verification artifact data can be retrieved from the local_services_verification_artifact resource. Here's an example query that retrieves data for all the license-related verification artifacts for a given client account:

SELECT
  local_services_verification_artifact.id,
  local_services_verification_artifact.creation_date_time,
  local_services_verification_artifact.status,
  local_services_verification_artifact.artifact_type,
  local_services_verification_artifact.license_verification_artifact.license_type,
  local_services_verification_artifact.license_verification_artifact.license_number,
  local_services_verification_artifact.license_verification_artifact.licensee_first_name,
  local_services_verification_artifact.license_verification_artifact.licensee_last_name,
  local_services_verification_artifact.license_verification_artifact.rejection_reason
FROM local_services_verification_artifact
WHERE local_services_verification_artifact.artifact_type = 'LICENSE'

Geographic and categorical license and insurance data

To programmatically determine the status of verification requests by geographic location, specifically, geo target code) and local services category ID, you can use a new field on the customer resource, called LocalServicesSetting.

This field exposes a high-level summary of the status of license and insurance verification requests by location and category. Here's an example query that retrieves all such data:

SELECT
  customer.local_services_settings.granular_license_statuses,
  customer.local_services_settings.granular_insurance_statuses
FROM customer