Documentation

Before you begin

BIG-FLYTX by MAS requires WordPress 6.2 or later and PHP 7.4 or later. WooCommerce is needed only for WooCommerce-specific events. Keep a current site backup and test configuration on a staging site when possible.

Install from a ZIP file

1. Sign in to WordPress as an administrator.
2. Open Plugins → Add New Plugin → Upload Plugin.
3. Choose the BIG-FLYTX by MAS ZIP package and select Install Now.
4. When installation completes, select Activate Plugin.
5. Open BIG-FLYTX → Settings.

If the plugin is offered in the WordPress plugin directory on your site, you can also search for “BIG-FLYTX by MAS” under Plugins → Add New Plugin and install it there.

Important: activation does not start tracking. BIG-FLYTX is paused by default. Review the privacy, consent and data-retention options first, then explicitly authorize tracking and enable only the integrations you intend to use.

After installation

Check the plugin’s health or diagnostics screen for setup notices. Choose a tracking mode, configure the required provider IDs or credentials, and test events before enabling production campaigns. Do not paste API secrets into public page content or share them in screenshots.

If WordPress reports an upload, PHP or compatibility error, note the exact message and check the site’s PHP error log before retrying. Avoid repeatedly uploading the same package while an install is in progress.

BIG-FLYTX starts in a paused state. Installing or activating it alone does not collect or transmit visitor events.

Recommended setup checklist

1. Open BIG-FLYTX → Settings as a WordPress administrator.
2. Read the Privacy, Compliance & Data Retention disclosure and decide which data your site is allowed to process.
3. Choose who manages visitor notice and consent. Use Site-owner managed mode if your existing privacy notice or consent-management platform handles this. Choose Strict visitor gate mode if BIG-FLYTX must wait for its consent signal before tracking.
4. Explicitly authorize tracking in the plugin and enable BIG-FLYTX.
5. Select one tracking mode that fits your existing setup.
6. Enable only the provider integrations you actually use, then add the relevant Pixel ID, Measurement ID, API token or endpoint.
7. Review raw personal-data storage, administrator masking and retention options.
8. Test on staging or with test events. Confirm that events are received once by the intended destinations.
9. Publish the configuration only after the privacy notice, consent flow and provider settings are ready.

Avoid duplicate tracking

Before enabling browser pixels, check whether your theme, tag manager, another analytics plugin or a marketing platform already loads the same pixel. If Google Tag Manager controls tags, use dataLayer Only. If you are diagnosing setup, start with Monitor Only.

BIG-FLYTX does not provide its own visitor consent banner. In Site-owner managed mode, the site owner remains responsible for the applicable notice and consent process.

BIG-FLYTX offers several delivery modes so it can fit different WordPress tracking setups. Choose one deliberately; enabling overlapping browser tags in multiple tools can create duplicate conversions.

Full Tracking

Use Full Tracking when BIG-FLYTX should manage browser tracking and any server destinations you explicitly configure. Enable only the providers and event types you need.

dataLayer Only

Use dataLayer Only when Google Tag Manager (GTM) should load and control the final tags. BIG-FLYTX publishes normalized event data to the dataLayer; configure GTM separately to map those events to your tags and triggers. Do not also install duplicate browser pixels through BIG-FLYTX unless you intentionally want both paths.

Server Only

Use Server Only when browser pixels are already managed elsewhere but you want BIG-FLYTX to send configured server-side events. Global server tracking, the destination-specific server toggle and the required credentials must all be configured. Server delivery is not automatic just because this mode is selected.

Monitor Only

Use Monitor Only while checking event capture and plugin behavior without sending events to advertising platforms. This is a useful first step for testing a new installation or investigating unexpected conversions.

Changing modes

After changing a mode, save the settings and run a test journey: view a page, submit a supported lead form or complete a test WooCommerce flow. Check BIG-FLYTX activity/diagnostics and the destination’s test tools. Confirm that the same action is not also being sent by another plugin or GTM container.

Choose how Google tags will be managed

Decide whether BIG-FLYTX or Google Tag Manager will load the browser tags. If GTM already manages GA4 or Google Ads, choose dataLayer Only to avoid loading a second copy of those tags from BIG-FLYTX.

Configure browser measurement

1. Open BIG-FLYTX → Settings and find the Google integration settings.
2. Enable only the Google destinations you use.
3. Enter the applicable GA4 Measurement ID and/or Google Ads conversion details exactly as issued by Google.
4. Save the settings and confirm the intended tracking mode.
5. Use the Google tag or GA4 DebugView tools to verify test events.

Configure GTM

1. Select dataLayer Only in BIG-FLYTX when GTM should control the tags.
2. In GTM, create triggers and tags that match the normalized events BIG-FLYTX publishes.
3. Preview the container and test a page view, lead or WooCommerce action.
4. Publish the GTM container only after the test events and consent behavior are correct.

Optional GA4 server delivery

GA4 Measurement Protocol delivery is optional. Enable global server tracking and the GA4 server destination, then enter the required administrator-managed credentials. Test server events and deduplication before using live campaign data.

Privacy note

Do not place secret API credentials in frontend code. BIG-FLYTX keeps configured credentials out of frontend JavaScript. Review the data sent to Google and describe your enabled integrations in your site privacy notice.

Before configuring Meta

Have the correct Meta Pixel ID and, if using server-side delivery, the required Conversions API credentials ready. These values are supplied by the site owner and must be kept private.

Browser Pixel setup

1. Open BIG-FLYTX → Settings and find the Meta/Facebook integration.
2. Enable the Meta Pixel destination and enter the Pixel ID.
3. Save, then test a page view and a supported conversion event using Meta’s test tools.

Optional Conversions API setup

1. Enable global server tracking and the Meta server destination.
2. Enter the required server-side credentials in the protected settings fields.
3. If both browser and server delivery are enabled, keep shared event IDs enabled/configured so Meta can match and deduplicate the same event.
4. Send a test event and confirm the browser and server copies are recognized as one event where applicable.

Troubleshooting

If browser events arrive but server events do not, verify the server destination toggle, global server tracking, credentials and server response/diagnostics. If counts are doubled, check whether another plugin or GTM also sends the same Pixel event. Do not solve duplicates by removing event identifiers without first checking the platform’s deduplication requirements.

Meta may receive event names, event IDs, timestamps, page/referrer information, advertising click IDs, commerce values and configured hashed identifiers. Review Meta’s terms and privacy information and disclose the integration to visitors.

BIG-FLYTX can capture WooCommerce product views, add-to-cart actions, checkout activity, purchases, order values, customer totals and revenue. It uses WooCommerce APIs and is designed to preserve compatibility with High-Performance Order Storage (HPOS) and Cart/Checkout Blocks.

Enable WooCommerce tracking

1. Confirm WooCommerce is installed and active.
2. In BIG-FLYTX settings, enable WooCommerce/ecommerce event capture.
3. Enable only the browser or server destinations that your store uses.
4. Review whether order/customer data may be collected under your privacy and consent setup.
5. Place a test order using a test payment method or staging store.
6. Check the BIG-FLYTX event activity/diagnostics and the configured destination’s test or debug view.

What to verify

Confirm product, cart, checkout and purchase actions appear at the expected step. Check the order value and currency, and verify that one test purchase is not sent repeatedly. When server and browser delivery are both used, confirm event IDs and destination deduplication are working.

Production safety

Do not test by placing repeated real orders on a live store unless you understand the payment and fulfillment effects. Use staging or a test payment flow whenever possible. BIG-FLYTX does not replace WooCommerce order records, payment processing or tax configuration.

BIG-FLYTX can route enabled events to supported browser tags, dataLayer or optional server endpoints. Available destinations include Meta, Google Analytics 4, Google Ads, Google Tag Manager dataLayer, Microsoft Ads UET, TikTok, LinkedIn, Pinterest, Snapchat, X, Reddit, Quora, Telegram and custom relays.

Configure only what you use

1. Open BIG-FLYTX → Settings and review the available integration sections.
2. Enable a destination only when your site has an account and a valid reason to send it events.
3. Add its Pixel ID, Measurement ID, API credential or endpoint where required.
4. Select a compatible tracking mode and save.
5. Send a test event and verify it in the provider’s test/debug tools.

Some integrations are browser-only; others can also support optional server delivery. Server events require global server tracking, the destination’s server switch and valid credentials. Check the specific provider settings and diagnostics; do not assume every destination sends server events by default.

Custom endpoints

For a custom relay, the site administrator chooses and configures the URL. Confirm who operates that endpoint, what information it receives, its security requirements and its privacy terms before enabling it. BIG-FLYTX does not guarantee or endorse an administrator-entered endpoint.

External-service disclosure

Depending on the enabled destinations, event names, event IDs, timestamps, URLs, referrers, UTM values, advertising click IDs, product/order details and configured identifiers may be sent to providers. Keep your privacy notice accurate as integrations change.

Paused by default

BIG-FLYTX does not collect or transmit visitor events merely because it is installed or activated. An administrator must authorize tracking, enable the plugin and configure a destination. If Strict visitor gate mode is selected, visitor consent is also required before collection or transmission.

Choose a consent approach

Site-owner managed mode: the site owner manages required visitor notice and consent through the site’s privacy process or its consent-management platform. BIG-FLYTX does not display its own consent banner.

Strict visitor gate mode: BIG-FLYTX waits for the documented bftx_consent=granted cookie or the bftx_mas_tracking_consent_granted filter before tracking. Make sure your consent platform sets the signal only after the visitor’s valid consent.

Data and storage controls

Depending on enabled features, event data can include visitor IDs, URLs, referrers, UTM values, advertising click IDs, browser/user-agent hashes, IP-address hashes, ecommerce data and safe lead/customer fields supplied by a form or commerce transaction. Raw name, email and phone storage is disabled by default; enable it only if your notice, legal basis and consent process permit it.

Review Do Not Track support, administrator data masking, event and delivery-log retention, WordPress personal-data export/erase support and the optional uninstall deletion setting. Set retention to match your operational and legal needs.

Site owner responsibility

The site owner is responsible for deciding whether tracking is lawful, maintaining an accurate privacy/cookie notice, configuring a consent platform where needed, and documenting each external provider and custom endpoint. This guide is technical information, not legal advice.

Use Monitor Only or a staging site first

For an initial check, choose Monitor Only so you can inspect event capture without sending events to advertising platforms. Confirm your consent configuration and required administrator authorization before any production collection.

Test checklist

1. Open BIG-FLYTX and confirm the plugin is enabled, the intended tracking mode is selected and the required destination is configured.
2. Open the site in a clean browser session and complete one simple action, such as viewing a page.
3. If applicable, submit a test lead form or perform a WooCommerce product, cart, checkout and test-purchase flow.
4. Review BIG-FLYTX Activity, Reports, Diagnostics or Health Check for the captured event and any delivery errors.
5. If browser delivery is enabled, use the provider’s browser pixel/tag debugger. For GA4, use DebugView; for GTM, use Preview mode.
6. If server delivery is enabled, inspect the provider’s test-event view and the plugin delivery status.
7. Confirm the event is delivered once. When browser and server copies represent the same action, verify event-ID deduplication.

After testing

Switch from Monitor Only only when the selected destinations are ready. Save the final settings, repeat one controlled test and record the configuration for future troubleshooting. Do not use real customer purchases or personal data as test payloads when safe test data is available.

If no events appear

1. Confirm BIG-FLYTX is explicitly authorized and enabled; activation alone leaves it paused.
2. Check the selected tracking mode. Monitor Only records for inspection but does not send to ad platforms.
3. In Strict visitor gate mode, confirm the visitor’s consent signal is set correctly. In Site-owner managed mode, confirm the site’s consent tool is not blocking the integration unintentionally.
4. Confirm the event source is supported and the relevant integration is enabled.
5. Recheck Pixel/Measurement IDs, API credentials and destination-specific server switches.
6. Use the plugin’s Diagnostics or Health Check and the provider’s test/debug tool. Check the WordPress/PHP error log for server failures.

If events are duplicated

1. Check whether the same pixel or tag is installed by the theme, GTM, another plugin and BIG-FLYTX at the same time.
2. If GTM controls tags, consider dataLayer Only and disable duplicate direct browser tags.
3. If using browser and server delivery together, verify that matching events share event IDs and that the destination accepts/deduplicates them.
4. Make one change at a time and repeat a single controlled test.

If browser works but server delivery fails

Confirm global server tracking and the destination’s server toggle are both enabled, the credentials are valid, outbound requests are allowed by the hosting provider, and the event is allowed by consent settings. Use delivery logs/diagnostics and the provider’s test view to locate the failing stage.

When asking for support, include the plugin version, WordPress/PHP/WooCommerce versions, tracking mode, affected event and a sanitized diagnostic message. Never send API tokens, customer personal data or full payment/order details.

BIG-FLYTX can capture lead events from supported form and page-builder integrations and connect first-party visitor, lead, customer and ecommerce activity in its dashboard. Exact events depend on the form or builder integration active on your WordPress site.

Set up lead tracking

1. Install and activate the form plugin or builder you already use.
2. Open BIG-FLYTX settings and enable the relevant supported form/builder source, if available.
3. Choose the destinations that should receive lead events and configure their IDs/credentials.
4. Review consent and personal-data options before testing.
5. Submit one test form with synthetic data and confirm the lead appears in BIG-FLYTX activity and the selected provider’s test tool.

Personal-data precautions

Raw name, email and phone storage is disabled by default. Only enable raw storage when your privacy process permits it. Do not use real visitor details in test forms. If a provider supports hashed matching, verify the configuration and disclose the data transfer appropriately.

If a form submission is not tracked, check that the form plugin is supported and current, the form source is enabled, required consent was received and the plugin diagnostics report no integration conflict. BIG-FLYTX does not guarantee compatibility with every third-party form plugin or custom form implementation.

Does tracking start as soon as I activate the plugin?

No. BIG-FLYTX is paused by default. An administrator must review the disclosure, authorize tracking and enable the plugin and intended destinations.

Does the plugin send server-side events automatically?

No. Server delivery requires global server tracking, the relevant destination’s server toggle and valid credentials. Consent requirements also apply.

Which mode should I use with Google Tag Manager?

Use dataLayer Only when GTM should control the final tags. Configure GTM triggers and tags separately and test them in Preview mode.

Can I use browser pixels and server events together?

Yes, for supported integrations, when both delivery paths are configured. Use event IDs and verify destination-side deduplication to avoid double-counting.

Does BIG-FLYTX support WooCommerce?

Yes. It can capture product, cart, checkout, purchase, order-value, customer and revenue events. It is designed to preserve HPOS and Cart/Checkout Blocks compatibility.

Does BIG-FLYTX show a consent banner?

No. The site owner must provide the visitor notice/consent process, usually through the site’s own privacy tools or CMP. Strict visitor gate mode can wait for the documented consent cookie or filter.

Is raw personal data stored by default?

No. Raw name, email and phone storage is disabled by default. Review all privacy controls before enabling it.

Does uninstall remove plugin data?

Only when “Delete BIG-FLYTX Tables on Uninstall” is enabled before uninstalling. Review and export any data you need before removal.

Before updating

1. Note the current BIG-FLYTX version and save a site/database backup.
2. Review the release notes and confirm compatibility with your WordPress, PHP and WooCommerce versions.
3. Update on staging first when possible, then test a page view, lead and WooCommerce event that matters to your site.
4. Review diagnostics and confirm the existing consent and destination settings remain correct.

Personal-data export and erasure

BIG-FLYTX includes WordPress personal-data export/erase support. Use WordPress privacy tools when responding to a valid data request, and follow your own retention and identity-verification process.

Uninstall behavior

Plugin-owned tables are not deleted by default when you uninstall. If you want uninstall to remove BIG-FLYTX tables, enable “Delete BIG-FLYTX Tables on Uninstall” before removing the plugin. Export any information you need first; deletion may not be reversible without a backup.

After uninstalling, check that no leftover GTM tags, theme snippets or other plugins continue sending the same events. Removing BIG-FLYTX does not automatically remove tracking code installed by separate tools.