Get access to a client's Google Merchant Center

Confirm the Merchant Center account associated with the correct store and product operation. Ask the client to identify the account they actually use for the work in scope, rather than choosing from a familiar-looking name. Also agree whether the immediate objective is assessment, configuration or ongoing delivery. These details determine which permission is reasonable and what your team will check afterward. If the client is unsure which asset belongs to the project, resolve that ownership or account-selection question before they approve access to an unrelated account.

The request needs a client Administrator on the selected Merchant Center account. Send the instructions to that person or ask the client to involve them. A staff member who can read a dashboard may still lack permission to invite an agency. Repeating the same request with the same insufficient role will not fix that distinction. The authorized person should review the requested asset, recipient and permission before proceeding, and retain their own independent access after the agency is added.

Read only and Performance reporting support review; Standard supports day-to-day feed work; Admin includes user and account administration. Select the role that matches the service agreement. Start by naming the actions the agency must carry out, then match the role to those actions. If the team only needs to inspect Google Merchant Center, explain why a viewing role may be sufficient. If a later task requires more authority, make that a deliberate scope decision with the client. Avoid requesting the broadest available role simply to prevent a possible future question; the current engagement should explain the permission being requested.

Agency Pilot sends an invitation at the selected access level. The agency accepts the Merchant Center email before relying on direct access to the account. Read the status in the context of that workflow. An invitation, a client confirmation and usable Google Merchant Center access are related milestones, but they do not always happen at the same moment. Assign responsibility for the next step before marking delivery as ready. This prevents an agency teammate from arriving at a scheduled task and discovering that a required acceptance or platform action is still outstanding.

Use the agency Google login that will review or manage the merchant account. Verify it before creating or sending the onboarding request, especially when the agency works through more than one account. Ask the actual recipient to confirm the identity they will sign in with. A forwarded email or a similar display name is not reliable proof that the correct account has been added. For a staffing change, arrange the replacement person’s appropriate access and remove obsolete assignments through the relevant platform process.

After the platform action, accept the invitation and open the expected merchant account, checking its identity against the client store before discussing feed changes. Record who performed that check and whether any required work remains blocked. Prefer a harmless viewing check over an unnecessary live edit. If a teammate cannot reach the asset, compare the actual recipient and role with the original request before asking the client to start again. Completion should mean the right person can reach the intended asset with the agreed capability, rather than only that a message or notification was received.

This integration creates the access invitation. It does not read products, feeds, promotions or settings, and it should not be presented as a Merchant Center data-import dashboard. Keep the client’s reporting expectation explicit in the service brief. If a metric is needed for a report, identify its source, date range and definition before promising that it will appear. A successful access step establishes only the capabilities described for this particular integration. It should not be used as evidence that another platform, a separate dataset or an unrelated source of business results has also been connected.

If no invitation appears, check the agency Google email, account selection and pending invitation before recreating the request. If the client cannot invite users, involve an account Administrator. Start with account identity and authority because those determine what the client can share. Write down the exact stage where the flow stopped rather than repeatedly recreating the same request. If Google Merchant Center shows an account-specific restriction, the appropriate platform administrator may need to resolve it first. Avoid broadening permissions or switching to another asset just to make a completion indicator appear; verify the intended account instead.

No. The documented connection creates a Merchant Center user invitation and does not read or change products, feeds, promotions or settings. Make that clear when scoping ecommerce reporting. After accepting access, an agency can carry out permitted work in Merchant Center, but that direct platform activity is separate from what the onboarding connection itself does.

The product explains that the available Merchant Center scope is broad even though this flow uses it for the invitation. Clients should read the consent screen and the stated integration purpose before agreeing. Avoid implying that a broad platform scope means the product imports or manages every type of merchant data. The operational behavior described for this integration remains the access invitation.

Only if the engagement includes work that requires those systems. Merchant Center, an advertising account and a store administration area have different responsibilities and access arrangements. For a shopping campaign project, document which team owns product data, advertising changes and storefront updates. Use the related integration guides to request the necessary additional permissions rather than treating a merchant invitation as access to the entire ecommerce stack.

No. Access enables an authorized person to investigate within the granted role. The cause of a product issue still needs to be identified and addressed through the appropriate source or platform process. Preserve the affected product or feed context and agree who is responsible for changing it. Do not promise approval or a particular advertising outcome merely because the agency has accepted an invitation.

Agree that in the delivery plan before making changes. Product data may originate from the store or a separate feed operation, and multiple teams can unintentionally make conflicting edits. Identify the authoritative source, the responsible person and how proposed changes are reviewed. This is an agency workflow recommendation; the Agency Pilot access connection itself does not select a feed source or synchronize product changes.

Remove the agency user in Merchant Center People and access, end the Agency Pilot connection, and review separate store or Google Ads permissions that were granted for the same engagement. Agree a handover point before removing access that is still needed to finish approved work. Confirm the business retains the people and permissions it needs after the agency leaves. Keep permission removal separate from decisions about delivered work or historical reporting data; those are different questions. Record which Google Merchant Center assignments were removed and which, if any, remain for an explicitly agreed support period, with a clear owner for the final review.

Review the client’s stated merchant issue in the accepted account and identify where the affected product information originates. Coordinate with the store or feed owner before editing, and request separate Google Ads or Shopify access only where the work requires it. Keep an example product or feed issue with the diagnostic note. The first useful action is to establish the cause and responsible system; the access integration does not import products or automatically resolve eligibility problems.