How to Set Up Google Ads Conversion Tracking for Solar Installers

To understand how to set up Google Ads conversion tracking for solar installers, define the accepted solar opportunity, map calls and forms to the CRM and project workflow, install the approved event path, and test it against service area, residential or commercial intent, system type, battery interest, consent, and site-assessment or proposal stages. Make a qualified enquiry, connected sales call, or booked assessment primary only when the installer can identify it later and separate it from a calculator user, financing question, job seeker, existing-customer request, duplicate, unsupported project, or out-of-area contact.

Solar sales paths are not interchangeable. A residential rooftop enquiry, a battery-storage question, a commercial multi-site request, a ground-mount project, a new-construction brief, and a warranty call can have different owners, review steps, service areas, and evidence. A form can be technically successful while the request is not serviceable or not a new acquisition. A phone call can be a real conversation while still being an existing-customer or utility-process request. The setup should preserve those states without claiming that a browser event proves a suitable roof, approved financing, an incentive, a design, a completed installation, or revenue.

Google’s web conversion setup guidance, primary and secondary conversion guidance, and Google tag guidance describe the platform components. The installer supplies the definitions, service-area and project rules, call routing, CRM and scheduler fields, design and proposal states, consent decisions, and approved value records. This is measurement guidance, not solar-design, electrical, roofing, permitting, tax, incentive, financing, legal, or safety advice. Project claims and customer-facing promises require the installer’s qualified review and the applicable authority or utility requirements.

Write the solar conversion contract first

Describe the path from ad or landing page to phone or form, solar enquiry, site assessment, design, proposal, contract, installation, inspection, commissioning, battery add-on, service, referral, cancellation, or customer-support outcome. For every candidate conversion, identify the system that proves the state and the stable ID connecting it to the preceding state. A browser event proves that configured code ran; the CRM, phone provider, scheduler, proposal system, project-management system, invoice, or approved offline record proves what happened in the installer’s process.

For each action, record:

its business meaning and truth condition;
the website, phone, form, CRM, scheduler, design, proposal, contract, project, invoice, or value source;
the service area, residential or commercial route, property or customer type, project category, battery interest, and timing rule;
the stable lead, call, appointment, assessment, design, proposal, contract, project, installation, service, referral, or cancellation ID;
the primary, secondary, diagnostic, or downstream role;
the consent and approved-data condition; and
the owner, test case, retention rule, and rollback decision.

Do not begin by making every solar page, calculator completion, financing click, battery comparison, phone click, or form start a primary conversion. Those signals may diagnose demand without representing a supported project. The setup should make clear which action can influence bidding, which action measures lead quality, and which later assessment, proposal, contract, installation, or value state is reconciled through the installer’s own systems.

Separate solar, battery, commercial, and service routes

Map the routes the installer actually offers: residential rooftop, residential battery, ground-mount, commercial rooftop, multi-site commercial, new construction, electrical upgrade, storage retrofit, monitoring, warranty, service, referral, and partner work. Preserve residential or commercial context, homeowner or property-manager role, broad market, property or roof type, system category, battery interest, urgency or timing category, project size band where approved, and serviceability when those fields change routing or qualification.

A homeowner requesting a site assessment is not the same record as a business asking for a multi-site design. A battery-only question may need a different technical review from a new installation. An existing customer needing monitoring or warranty work belongs to a service path, not necessarily a new-acquisition path. Tracking can describe the route without claiming that the roof is suitable, the utility will approve interconnection, financing will be approved, an incentive will apply, or a stated savings outcome will occur.

Define the evidence for every status

Use the installer’s real workflow states. A contact may be received, serviceability checked, qualified, scheduled, assessed, designed, proposed, accepted, contracted, scheduled for installation, installed, inspected, commissioned, referred, cancelled, or marked as existing-customer support. The exact labels can differ, but each transition needs a source record and an owner.

Write down what changes one state to another. A site-assessment request is not a completed assessment. A proposal sent is not a signed contract. A signed contract is not an installed or commissioned system. A financing request is not financing approval. The status map is the foundation for deciding which event is safe to send to Google Ads and which belongs only in internal reporting.

Prepare the installer’s source systems

Before adding a tag, inspect the website form handler, phone provider, consent manager, CRM, scheduler, design or proposal tool, project-management system, invoice process, and approved offline records. Decide which system owns each field and how a status change is represented. If a call provider records a connected call while the CRM records an accepted battery enquiry, those are related facts, not automatically the same conversion.

Build a solar event table

Use a table that makes the truth condition and reporting role explicit:

Event	Evidence that it happened	Useful connection	Possible role
Solar page view	Page renders for the requested topic	Topic and broad market context	Secondary
Calculator or battery-tool use	Approved interaction completes	Tool version and non-sensitive context	Secondary
Phone click	Visitor activates a phone link	Number, page, and timestamp	Secondary
Connected sales call	Provider records a connection	Call and routing IDs	Secondary or candidate
Solar enquiry accepted	CRM accepts a request to review	Lead ID, serviceability, and disposition	Primary candidate
Site assessment booked	Scheduler confirms an appointment	Appointment and lead IDs	Primary candidate
Proposal accepted	Approved sales record changes state	Proposal, project, and lead IDs	Downstream
Installation completed	Project system records completion	Project, completion, and lead IDs	Analysis or value

The table is an internal map, not a command to send every state to Google Ads. Use it to decide what can influence bidding, what diagnoses lead quality, and what is reconciled later through the CRM, phone system, scheduler, design or proposal system, project-management system, invoice, or approved offline process. The best Google Ads conversion tracking for solar installers article provides the broader decision framework.

Choose the source of truth before implementation

The website can prove that a form was accepted by its own handler. The phone provider can prove a call connection according to its record. The CRM can prove that the installer reviewed and classified an enquiry. The scheduler can prove an assessment appointment. The design or proposal tool can prove a sales state. The project system can prove scheduled, installed, inspected, or commissioned states when its own record says so.

For each event, write the source system, status, identifier, timestamp convention, time zone, consent state, and owner. If two systems disagree, do not silently choose the larger number. Record whether the cause was a retry, delayed entry, call routing, partner handoff, duplicate merge, reschedule, cancellation, offline sale, or a mismatched customer record. A setup is dependable when another person can trace the event to the record that proves it.

Create and name conversion actions

Create one conversion action for each materially different business meaning instead of using one vague “solar lead” event for every interaction. Names should reveal the state and route, such as qualified_solar_enquiry, site_assessment_booked, or proposal_accepted, with additional dimensions stored in approved first-party systems. Keep a name stable while its truth condition is stable; use a documented migration when the meaning changes.

Write a definition that another salesperson, installer, analyst, or developer can apply without guessing. “Accepted solar enquiry” might mean that the company serves the market, supports the project category, can contact the person, and has not classified the record as spam, duplicate, existing-customer service, warranty, partner-only work, job seeker, unsupported project, or out of area. It should not mean “any submit button clicked” in one campaign and “completed installation” in another.

Record the trigger, source record, timestamp, stable ID, service area, residential or commercial route, system category, battery interest, property or customer type, consent state, disposition, and conversion role. If one page serves residential and commercial requests, preserve the distinction in the approved first-party system rather than creating a misleadingly generic action. If separate actions are needed for genuinely different outcomes, document how they roll up without counting the same project twice.

Select the earliest reliable primary state

Use Google’s primary and secondary conversion guidance when assigning roles. A qualified solar enquiry, genuine connected sales call, or booked site assessment can be primary when the installer defines, observes, and reconciles it consistently. A proposal, contract, installation, battery add-on, service, or invoice may be a later outcome valuable for analysis or an approved offline workflow, but it is not automatically the right web signal for bidding.

Choose the earliest state that is meaningful and reliably recorded. Waiting for installation completion can make the signal delayed and sparse; counting every calculator use, incentive question, or form start can make it noisy and optimistic. Keep assessment, design, proposal, contract, installation, inspection, commissioning, service, cancellation, and invoice evidence in the installer’s reporting model while allowing Google Ads to receive only the permitted signal matching the campaign’s purpose.

Do not let an action name overstate what it proves. A solar_lead event should not mean a suitable roof. A site_assessment_booked event should not fire on a battery-page view. A project_completed event must be tied to the project state that establishes completion, not to a thank-you page or a sales representative’s draft note. Name, trigger, owner, and source record must agree.

Keep diagnostic actions secondary

Calculator starts, battery-tool use, financing-page clicks, incentive-content views, phone clicks without a connection, chat starts, brochure downloads, and generic form starts can be useful diagnostics. They show interest or friction, but they do not necessarily show a serviceable project. Mark them secondary unless the installer has a specific, evidenced reason to treat one as a primary business outcome.

If campaign performance looks weak, do not promote diagnostic actions simply to increase the reported conversion count. First inspect service-area wording, landing-page promise, project-category routing, form validation, call handling, response time, assessment availability, and the relationship between the selected primary action and downstream assessments, proposals, contracts, and installations.

Install the web and phone paths

Use the approved implementation path for the site and connected systems. Google’s web conversion setup documentation describes how a website data source and Google tag can be found or set up, while Google’s tag documentation covers the tag foundation. The exact tag manager, consent, call, CRM, scheduler, proposal, project, invoice, and offline-import implementation depends on the installer’s technology, permissions, data policy, and professional oversight.

If Google Ads detects an existing Google tag or linked analytics property, verify ownership and purpose before connecting anything else. Do not add a second site-wide tag because a new conversion action was created. If no approved tag exists, follow the current Google setup flow and document where the tag is installed, which system owns it, what consent checks it, and which environments are included.

Fire the form event after acceptance

For a form, define the point at which the installer accepts the enquiry. A submit-button click can occur before field validation, consent capture, spam filtering, service-area checking, project-category routing, CRM creation, or a response from the form handler. Prefer an event from the approved form or CRM path that establishes acceptance, and pass the stable lead ID or a safe reference needed for reconciliation.

Test refresh, back-button use, failed validation, duplicate submission, timeout, server error, consent decline, consent change, out-of-area selection, unsupported project selection, and a CRM failure after the browser shows a success message. A success page should not fire a qualified-enquiry conversion if the source system rejected the record. If the website cannot know the final state, record a lower-confidence submission event as secondary and promote the authoritative state only through an approved later path.

Separate phone clicks from real sales calls

For calls, distinguish a phone-link click, call attempt, connected call, qualified conversation, site-assessment booking, proposal, contract, installation, service request, and existing-customer call. A click proves intent to call; the phone provider or CRM must prove the state chosen as the business conversion. Missed calls, callbacks, transfers, repeat callers, shared numbers, after-hours routing, partner calls, warranty, monitoring, and service requests need explicit relationship rules.

Do not use a single call-duration threshold unless the installer’s own process has defined and validated it. Duration can be a diagnostic field, not proof of a serviceable project. Use call disposition, service area, project category, customer role, lead ID, and the approved sales outcome where those are available. A short call can be a qualified assessment booking; a long call can be a financing or existing-customer question.

Keep one event path per intended meaning

Avoid firing the same conversion from both a button click and a thank-you page, or from both a client-side event and a server-side confirmation, unless deduplication and ownership are deliberately designed. Use a transaction or event ID where the approved implementation supports it, and test retries, redirects, page refreshes, single-page navigation, delayed CRM responses, and server retries.

For every event, write down the expected count in a controlled test: one form acceptance should produce one accepted-enquiry record; a browser refresh should not create a second lead; a callback should relate to the existing record; a rescheduled assessment should update or relate to the appointment; and a cancelled project should change downstream state without becoming a new acquisition. The test should inspect both Google-side behavior and the source-system record.

Preserve IDs and consent across the setup

Give the lead, call, appointment, site assessment, design, proposal, contract, project, installation, service, referral, cancellation, and value records stable identifiers in their authoritative systems. A visitor can submit a form twice, call after submitting, ask about both solar and a battery, reschedule an assessment, or return later as an existing customer. The setup should connect those facts without creating a fresh acquisition conversion for every interaction.

The identity should survive handoffs between the site, phone provider, CRM, calendar or scheduler, design and proposal tools, project-management system, invoice process, and any approved offline workflow. It does not need to expose the complete customer or project file to Google Ads. It needs to let the installer answer which measured interaction led to which business record and what that record became.

Deduplicate retries, calls, and appointments

Test a form retry, browser refresh, phone click without a call, missed call followed by callback, transferred call, repeat caller, battery enquiry that becomes a solar enquiry, residential-to-commercial correction, partner referral, assessment reschedule, proposal revision, existing-customer request, and cancellation. Keep the record that represents the real business state, and document whether other events are merged, related, rejected, or retained as service interactions.

Do not use an exact timestamp, page view, browser session, roof photo, utility bill, phone number, email address, or address as the only identity. Those values can be missing, repeated, corrected, or inappropriate for an advertising event. A stable source ID lets the installer reconcile acquisition with sales and project records while preserving the distinction between a new contact, follow-up, design, assessment, installation, and service request.

Do not overwrite a lead when the project category changes. If a homeowner starts with rooftop solar and later adds storage, show the relationship between the original opportunity and the add-on. If an existing customer calls about monitoring or warranty, keep the service record separate from acquisition. If a landlord, tenant, property manager, general contractor, or partner submits a request, preserve the role and routing outcome rather than forcing it into a homeowner-installation bucket.

Review consent before sending fields

Review consent choices, privacy notice, retention, access controls, customer-data terms, approved integrations, and applicable advertising requirements before sending lead fields to Google Ads or another measurement system. Google’s conversion measurement and data-use guidance and consent-management guidance are platform resources; they do not decide which fields an installer may collect, share, or retain in a particular jurisdiction.

Document which fields are necessary, which event is permitted under each consent state, how a consent change affects the measurement path, and where data may appear in forms, calls, CRM records, schedulers, design tools, proposal systems, project files, debugging tools, exports, or vendors. Keep the advertising event as a measurement signal, not a copy of a roof, utility, financing, contract, or customer file.

If the installer uses enhanced conversions or another customer-data feature, follow the current Google requirements and the organization’s approved data policy. Google’s enhanced conversions for web documentation explains the platform feature, but the decision to collect or share a particular first-party field still belongs to the installer and its privacy process. Do not add an integration merely because it could increase matching; establish the purpose, permitted fields, consent path, retention, access, and deletion process first.

Minimize property and financial data

An event may need a stable first-party ID, source, event name, residential or commercial route, broad market, property or customer type, system or service category, battery interest, serviceability, channel, value category, and consent state. It should not become a copy of roof photos, utility bills, electrical diagrams, access codes, identity documents, payment data, financing applications, contract files, exact property plans, or unnecessary household or business details. A conversion does not establish a design, energy-production forecast, interconnection approval, financing approval, incentive, or completed installation.

Use fictional or controlled records for testing. Test consent granted, declined, changed, and unavailable; residential, commercial, battery, ground-mount, new-construction, multi-site, service, warranty, referral, and partner paths; homeowner, tenant, landlord, property-manager, and existing-customer roles; out-of-area, unsupported, duplicate, rejected, cancelled, and rescheduled states; and assessment, design, proposal, contract, installation, inspection, commissioning, and invoice outcomes. Record the consent-management, phone, CRM, scheduler, design, proposal, project, tag, and release versions so a mismatch can be tied to a real change.

Connect CRM, assessments, proposals, and installations

The setup is useful when it explains what happened after the initial enquiry. Connect the original lead or call record to site assessment, design, proposal, contract, installation, inspection, commissioning, battery add-on, service, invoice, referral, cancellation, and approved-value states in the installer’s systems. The relationship may be one-to-many: a property manager can request several sites, and one enquiry can result in no installation or multiple approved projects.

Map the downstream handoffs

For each transition, identify the source owner and matching key:

The website or phone system records the incoming interaction and creates or references a lead or call ID.
The CRM records serviceability, customer or property type, project category, consent state, disposition, and qualification status.
The scheduler records whether an assessment is booked, rescheduled, attended, missed, or cancelled.
The design or proposal system records the appropriate design, proposal, revision, acceptance, or decline state.
The contract or project system records accepted scope, scheduled installation, installed, inspected, commissioned, cancelled, or otherwise approved project state.
The invoice or approved value process records the financial state that it is authorized to report.

The exact systems can differ. What cannot differ is the evidence rule: a later state should come from the system that owns it, and the relationship to the original acquisition record should be traceable. Do not use a thank-you page to stand in for a signed proposal or use a proposal amount to stand in for completed revenue.

Reconcile by stage and reporting window

Compare Google Ads actions with phone, form, CRM, scheduler, site-assessment, design, proposal, contract, project, installation, inspection, commissioning, battery add-on, service, invoice, referral, cancellation, and approved-value records over an appropriate reporting period. Explain differences caused by attribution or reporting delay, call routing, duplicate merging, consent, browser behavior, time zones, seasonal demand, partner handoffs, rescheduling, no-shows, cancellations, financing review, utility review, or offline work.

Segment by residential or commercial route, system category, battery interest, service area, property or customer type, broad market, call versus form, landing page, campaign, device, enquiry disposition, assessment state, proposal state, contract state, installation state, partner source, cancellation, referral, warranty, service request, and approved value. A mismatch limited to commercial proposals needs a different investigation from a missing event across every residential form and phone route.

When website events exceed CRM records, inspect form validation, retries, consent handling, duplicate logic, response failures, and whether the website reported success before the CRM accepted the request. When CRM records exceed website events, inspect phone routing, manual entry, partner referrals, offline sources, call tracking, and imports. When assessments exceed qualified enquiries, inspect direct traffic, repeat customers, partner work, or a status mapping that counts a later state twice.

If an approved offline process is used, document its matching key, source owner, status mapping, timestamp, consent state, project category, customer or property type, service area, value category, and data owner. A later import should improve evidence about lead quality or project value; it should not expose a project file or make an estimate look like realized revenue. Keep the original source and current business state available so reporting can distinguish “generated the enquiry” from “produced the completed project.”

Test the complete solar setup

Use an approved test environment and controlled contacts. Google Tag Assistant can help inspect tag behavior, but a browser event is not proof of a qualified solar enquiry, connected call, site assessment, proposal, contract, installation, inspection, commissioning, battery add-on, service outcome, or invoice. Compare the event with the form handler, phone provider, CRM, scheduler, design or proposal system, project-management system, invoice system, and approved offline record that establishes the business state.

Cover project, customer, and consent cases

Test a solar landing page, battery page, savings or design tool, phone click, connected call, missed call and callback, residential form, commercial form, ground-mount or new-construction route if supported, multi-site route if supported, service or warranty request, partner referral, homeowner, tenant, landlord, property manager, existing customer, financing question, incentive question, utility or interconnection question, out-of-area contact, unsupported project, duplicate form, rejected enquiry, booked assessment, reschedule, no-show, proposal, contract, cancellation, installation, inspection, commissioning, and invoice state. If the installer serves multiple markets, languages, property types, or project categories, test each materially different route.

For every test, record:

the truth condition, event name, conversion role, expected trigger, and source record;
stable lead, call, appointment, assessment, design, proposal, contract, project, installation, service, referral, cancellation, and value IDs as applicable;
broad market, residential or commercial route, property or customer type, system or service category, battery interest, serviceability, source, value category, and channel;
consent state and whether the approved data path allowed the event; and
expected deduplication, partner handoff, assessment reschedule, cancellation, downstream match, and rollback result.

Diagnose a missing, extra, duplicate, or wrongly valued event by inspecting the trigger, validation, consent state, phone routing, CRM creation, service-area rule, project-category rule, customer classification, scheduler state, design state, proposal state, contract state, project state, invoice state, tag version, and import timing. Test mobile as well as desktop, calls as well as forms, and declined or changed consent as well as the successful path. Do not add tags or change campaign definitions to conceal poor lead quality or a source-system mismatch.

Verify the conversion action status

After a controlled event, check the relevant conversion action using the current Google Ads interface and the source record. Confirm that the event name, action, page or call path, consent state, primary or secondary role, value behavior, and timestamp are the ones intended. A technical status such as a tag being detected does not establish that the CRM accepted the lead or that the campaign received the right business signal.

If a test does not appear, inspect the page or call trigger, tag ownership, consent state, data-layer or server response, duplicate logic, source-system creation, time zone, import delay, and conversion-action configuration. If it appears twice, trace every firing path before changing the action. If the event appears with the wrong value or stage, fix the source mapping and identity relationship rather than renaming it to make the report look plausible.

Test after releases and workflow changes

Repeat the relevant controlled tests after changing the form, landing page, tag manager, consent platform, phone provider, CRM, scheduler, design or proposal process, project system, status names, service area, product mix, partner workflow, or value model. A tag can continue to fire while the business meaning behind the event has changed. Keep the configuration or release version beside the test evidence so a later mismatch can be dated and traced.

Avoid common setup mistakes

Making every solar page, calculator completion, battery comparison, financing click, incentive question, phone click, chat start, or form start a primary conversion.
Counting job seekers, suppliers, electricians seeking work, existing customers, monitoring or warranty requests, partner contacts, out-of-area properties, unsupported projects, duplicates, and utility-process questions as new installations.
Treating an assessment request, design, proposal, contract, deposit, scheduled installation, inspection, commissioning, or invoice as a guaranteed project result.
Combining residential rooftop, battery, ground-mount, commercial, multi-site, new-construction, electrical-upgrade, storage-retrofit, and service paths without meaningful project context.
Firing a conversion on a button click and a thank-you page, or on both client-side and server-side paths, without deliberate deduplication.
Creating a new lead or project ID for a form retry, callback, transfer, battery add-on, assessment reschedule, design revision, follow-up, referral, service request, or cancellation.
Using a call-duration threshold as proof of a qualified solar opportunity without validating it against the installer’s own dispositions and source records.
Sending roof photos, utility bills, electrical diagrams, access codes, identity records, payment data, financing applications, contract files, exact property plans, or unnecessary household or business details to an advertising platform.
Presenting an estimated system price, expected savings, incentive, financing amount, energy-production estimate, contract value, or lifetime value as realized revenue.
Ignoring service area, customer or property role, consent, retention, access, data-use terms, approved integrations, project ownership, partner handoffs, no-shows, cancellations, utility review, or long sales-cycle delays.
Testing only a successful desktop residential form and never checking mobile, calls, battery, commercial, service, partner, duplicate, out-of-area, assessment, proposal, cancellation, installation, or declined-consent paths.
Changing conversion definitions or campaign settings to conceal a source-system mismatch instead of tracing the event, identifier, stage transition, and authoritative record.

The most damaging setup error is a conversion name that promises more than its evidence. “Solar lead submitted” and “completed installation” should not be interchangeable labels. Clear action names help the sales team, analyst, and campaign owner make different decisions from the same data.

Solar-installer setup checklist

Before relying on the account, confirm that:

Page, calculator, phone, form, enquiry, assessment, design, proposal, contract, installation, inspection, commissioning, battery add-on, service, referral, cancellation, invoice, and value boundaries are written down.
Every action has a meaning, truth condition, trigger, source record, serviceability rule, project category, role, owner, test case, consent condition, and rollback.
The site has one owned, documented tag foundation and no duplicate event path for the same intended meaning.
Form acceptance is separated from button clicks, and phone clicks are separated from connected or qualified calls where the business requires it.
Stable IDs connect lead, call, appointment, assessment, design, proposal, contract, project, installation, service, referral, cancellation, and value records.
Residential or commercial route, broad market, property or customer type, system or service category, battery interest, serviceability, consent, and disposition are explicit where they affect qualification.
Modeled enquiry, booked assessment, proposal, accepted contract, scheduled installation, completed project, invoice, realized revenue, and contribution values remain distinct.
Financing, incentive, utility, interconnection, savings, design, and energy-production questions are tracked as intent or approved states, not unsupported promises.
Privacy, consent, retention, access, customer-data terms, approved integrations, data owners, and professional review responsibilities are documented.
Desktop, mobile, residential, commercial, battery, ground-mount, new-construction, multi-site, service, warranty, partner, call, form, duplicate, out-of-area, assessment, proposal, contract, installation, cancellation, invoice, and declined-consent tests pass.
Google Ads, phone, form, CRM, scheduler, design, proposal, contract, project, installation, invoice, referral, cancellation, and approved-value evidence can be reconciled by stable ID and reporting window.

Keep an evidence trail

Record the event definition, source owner, identifier, consent path, conversion role, value model, test result, configuration or release version, and review date. When a number later looks wrong, this record lets the installer trace whether the issue began in the ad destination, tag, form, call route, CRM, scheduler, proposal process, project system, import, or reporting window. It also prevents the team from re-arguing the meaning of a conversion every time a campaign changes.

Practical next steps for solar installers

Begin with the shortest useful setup: define a serviceable enquiry or connected sales call, identify the authoritative record, install one approved event path, and make its primary or secondary role explicit. Then connect assessment, proposal, contract, installation, battery add-on, service, and value states as the sales and project systems can prove them. This produces useful visibility without pretending that a long downstream cycle is already available at the first click.

If the account already has tracking, inventory the existing conversion actions before adding more. For each one, ask what triggers it, what record proves it, whether it is included in bidding, how duplicates are handled, which consent states permit it, what value it carries, and whether it can be connected to an assessment or project. Retire or reclassify ambiguous actions only after their reporting impact and ownership are documented.

For the broader framework, see best Google Ads conversion tracking for solar installers, best Google Ads conversion tracking settings, best Google Ads bid strategy for solar installers, and best Google Ads location targeting for solar installers. adz.so can help organize measurement evidence and review steps around the installer’s definitions. It does not design solar systems, assess roofs, approve financing or incentives, guarantee savings, perform electrical or roofing work, replace the CRM or project systems, or provide legal, tax, utility, or safety advice.