Track the accepted action, not the click.

Write one sentence naming the outcome, the success condition and the system that confirms it. For the fictional repair studio: ‘An inquiry is accepted when the server stores a valid request and assigns its request ID.’ Opening the form or pressing Send is earlier behavior. A paid repair is a later outcome that needs its own definition.

Include the important failure cases. An invalid form, rejected payment or canceled booking should not become the completed outcome merely because the visitor reached a similar screen. Identify the responsible owner and the evidence they can inspect. A success message is useful, but it should agree with the actual accepted record.

List the possible senders for the same outcome: direct site code, a tag manager, an analytics import, a platform integration or a later business-system import. A missing sender can leave a gap; several uncontrolled senders can duplicate the signal. Choose a documented route and explain any deliberate additional records and duplicate handling.

Keep the event’s identity and meaning consistent. If a supported setup uses an order or event identifier, check that it represents the same real outcome on retries. Do not assume that a new page load means a new inquiry. Work with the site’s existing data-choice and privacy configuration; a server-side route or hashed value does not make all collection automatically appropriate or complete.

For standard goals, Google says primary actions are used for bidding when their associated goal is selected, while secondary actions generally appear for observation in All conversions. A custom goal can use an included secondary action for bidding. Review the actual campaign goal as well as the action label; ‘secondary never affects bidding’ is too broad.

The One or Every count setting belongs to each conversion action. Google describes One as one conversion per ad click for that action, rather than one customer forever across the account. Every can count multiple valuable actions after an interaction. These settings do not repair an incorrect trigger or automatically merge separately defined duplicate actions. Record value, currency, window and attribution choices where relevant instead of copying unexplained defaults.

Use a controlled permitted test path and save the timestamp, expected result and non-sensitive test identifier. Check the business record, inspect the event with appropriate diagnostics and review the intended conversion action after its normal processing interval. Google lists Tag Assistant as a verification tool. One green status alone does not establish all three layers.

Test an invalid attempt, one accepted action and a repeat or refresh path. Distinguish event not sent, event rejected, event not attributed and event not yet reported. Attribution windows, reporting dates, processing and available data can explain differences between systems; they are reasons to investigate, not to force totals to match. Repeat the relevant checks after a material form, tag, goal or import change, and avoid judging the newest incomplete period as if it were fully mature.