外掛標籤
開發者團隊
原文外掛簡介
AttentionVerify by OMNIYA is a WordPress plugin that uses camera-based attention verification to reward customers for genuinely watching a video on your WooCommerce product pages. When a customer reaches the required attention score, the plugin creates a single-use WooCommerce coupon for them.
How It Works
The store owner assigns a video to a WooCommerce product from the wp-admin settings page
The customer visits the product page and the attention widget appears automatically, no shortcode needed
The customer allows camera access, clicks “Start Verification” and watches the video
MediaPipe face detection runs in the customer’s browser and monitors face presence, head pose and tab focus
At 95% or higher verified attention, a unique single-use WooCommerce coupon is generated and shown to the customer
Key Features
Real-time face detection and attention timer (runs in the browser)
WooCommerce coupon reward on verified completion
Analytics dashboard: sessions, attention score, dwell time, coupon history
Anti-cheating checks (tab switch, head pose)
Session logging in your own Firebase Firestore project
Optional “Powered by AttentionVerify” watermark (off by default, the site admin can opt in from Settings)
No WooCommerce API keys required: coupons are created with WooCommerce’s own native functions
Privacy and Data
Please read this section before using the plugin on a live store. The widget uses the visitor’s camera, so you should mention it in your privacy policy and, depending on where your visitors are, obtain their consent before the widget starts. This is general information, not legal advice.
In the visitor’s browser
The camera stream is processed locally by MediaPipe to detect face presence and head pose.
The plugin does not store or transmit camera frames, images or video.
The browser also estimates an approximate gender label and age range from facial landmark measurements. Only these two labels (not images or facial measurements) are sent to your site and saved with the session analytics.
In your Firebase project (the project whose credentials you enter in Settings)
Per the Firestore rules shown below, the widget writes a session document with: session ID, product/ad ID, completion status, attention duration, counters (face lost, head moved, tab switches, failures) and timestamps, plus small event records (type, message, timestamp) and aggregate watch-time totals.
The plugin’s author does not receive this data. Each site uses its own Firebase project.
In your WordPress database
A session analytics log in the options table (the most recent 1000 sessions): session ID, product ID, attention percentage, dwell time, status, coupon code, estimated gender and age range, and date.
For logged-in customers who complete verification: user meta recording that verification happened (verified flag, last session ID, ad ID, attention percentage, completion time).
Short-lived rate-limit counters (WordPress transients) keyed by a hash of the visitor’s IP address. The plugin does not store raw IP addresses.
Privacy and Security
Your Firebase web configuration (API key, project ID and so on) is stored in WordPress options and delivered to the visitor’s browser, because the widget needs it to connect to Firestore. Firebase web configuration values identify your project; they are not secrets. Access is controlled by your Firestore Security Rules and, optionally, Firebase App Check (see below).
The plugin never needs a Firebase Admin SDK key or service-account key. Never paste one into the plugin settings.
Coupons are only issued after your server confirms in your own Firestore project that the session was marked as verified.
Recommended Firestore Security Rules are provided below. Apply them in your Firebase project’s console.
Firestore Security Rules
This plugin writes session documents directly to your own Firebase project from the browser (there is no server-side Firebase Admin SDK involved). Apply the following rules in your Firebase Console under Firestore Database → Rules. They constrain writes to the exact shape this plugin uses, and prevent a session document from being rewritten once it reaches a terminal state:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /sessions/{sessionId} {
allow get: if true; // required so the plugin's server-side verification (a public, unauthenticated read) can confirm completion status before issuing a reward
allow list: if false;
// hasOnly (not just hasAll) is what actually prevents a client from
// attaching an extra field — an "image", "face_data", "video", or
// anything else — alongside the required ones. hasAll alone only
// checks that the required keys are present; it does not stop
// additional keys from being included in the same write.
allow create: if request.resource.data.keys().hasAll(['session_id','ad_id','completion_status','created_at'])
&& request.resource.data.keys().hasOnly(['session_id','ad_id','completion_status','attention_duration','face_lost_count','head_moved_count','tab_switch_count','fail_count','created_at','updated_at'])
&& request.resource.data.completion_status == 'in_progress'
&& request.resource.data.session_id is string
&& request.resource.data.session_id.size() < 200;
allow update: if resource.data.completion_status == 'in_progress'
&& request.resource.data.keys().hasOnly(['session_id','ad_id','completion_status','attention_duration','face_lost_count','head_moved_count','tab_switch_count','fail_count','created_at','updated_at'])
&& request.resource.data.session_id == resource.data.session_id
&& request.resource.data.ad_id == resource.data.ad_id
&& request.resource.data.completion_status in ['in_progress', 'verified', 'failed'];
allow delete: if false;
match /events/{eventId} {
allow create: if request.resource.data.keys().hasAll(['type','message','timestamp'])
&& request.resource.data.keys().hasOnly(['type','message','timestamp']);
allow read, update, delete: if false;
}
}
match /publisher_stats/totals {
allow get: if true;
allow list: if false;
allow write: if request.resource.data.keys().hasOnly(['total_seconds_watched','completed_attention','uncompleted_attention','updated_at']);
allow delete: if false;
}
match /{document=**} {
allow read, write: if false;
}
}
}
Important limitation, stated plainly: these rules constrain the shape of what can be written (field names, types, and that a completed session can’t be silently reset), but they cannot verify that the attention percentage a browser reports actually came from a real, live camera check. That verification happens entirely client-side, which is an inherent characteristic of any browser-based, unauthenticated verification flow like this one, not something rules alone can close. A determined person with a scripted client could therefore obtain coupons without really watching the video. Treat the reward as a low-value incentive: keep the discount modest, use WooCommerce’s own coupon restrictions, and enable Firebase App Check (below).
Firebase App Check (Recommended)
Firebase App Check is an additional layer on top of the Firestore rules above: it verifies that requests reaching your Firestore database are genuinely coming from your own site’s widget, not a scripted client that has simply copied your public Firebase config. This is configured per-project directly in your own Firebase Console. The plugin cannot enable or enforce it for you, so it’s a setup step you take yourself, once, per Firebase project. Once you’ve done the Console steps below, this plugin’s Settings page has a matching field so the widget can start sending App Check tokens.
Step 1: Register a reCAPTCHA v3 site key (free):
Go to https://www.google.com/recaptcha/admin/create
Choose reCAPTCHA v3
Add your site’s domain
Copy the generated Site Key (you’ll paste this into the plugin’s Settings in Step 3)
Step 2: Enable App Check in the Firebase Console:
Open your project in the Firebase Console
Go to App Check in the left-hand menu (under Build)
Register your web app, choosing reCAPTCHA v3 as the provider, and paste in the Site Key from Step 1
Under Firestore Database → App Check, start in Monitoring mode first (not Enforced). This lets you confirm real traffic is passing before you risk blocking genuine visitors
After a day or two of monitoring shows your site’s own requests passing normally, switch Firestore to Enforced
Step 3: Give the plugin the Site Key:
Go to AttentionVerify → Settings in wp-admin
Under Firebase Configuration, paste the same reCAPTCHA v3 Site Key from Step 1 into App Check Site Key
Save. The widget will automatically start attaching App Check tokens to its Firestore requests
Leaving the App Check Site Key field blank is safe: the plugin functions exactly as before, App Check simply isn’t used (and no App Check or reCAPTCHA scripts are loaded). This is an additional safeguard on top of the Firestore rules above, not a replacement for them; apply both.
External Services
This plugin connects to the following external services. Please review their terms and privacy policies before using the plugin.
Firebase / Google Firestore
Used to log session data and to let your server confirm that a session was verified before a coupon is issued. The Firebase JavaScript libraries are bundled with the plugin (they are not loaded from a CDN). The project used is the one you configure in Settings.
Browser to Firestore: session ID, product/ad ID, completion status, attention duration, counters and timestamps (see “Privacy and Data”).
Your WordPress server to firestore.googleapis.com: a read of the session document (by session ID) in your own Firebase project, performed when a coupon is requested.
When: while a visitor runs the verification widget, and when a coupon is requested.
Terms: https://firebase.google.com/terms | Privacy: https://policies.google.com/privacy
Firebase App Check and Google reCAPTCHA v3 (optional)
Only used if you enter an App Check Site Key in Settings. The Firebase App Check library is bundled with the plugin (not loaded from a CDN). When a Site Key is set, Google reCAPTCHA v3 runs in the visitor’s browser to obtain App Check tokens, which means the visitor’s browser contacts Google. As with any request to Google, the visitor’s IP address and browser details are visible to Google.
When: while the widget is open on a site that has an App Check Site Key set.
Terms: https://policies.google.com/terms | Privacy: https://policies.google.com/privacy
MediaPipe (Google) – bundled locally
Used for real-time face detection and attention tracking. The MediaPipe Face Mesh and Camera Utils libraries (Apache-2.0), including the WebAssembly and model files, are bundled inside the plugin in attentionverify-app/vendor/mediapipe/. Nothing is loaded from a CDN and no request is made to MediaPipe, Google or jsDelivr for face detection.
Data: detection runs entirely in the visitor’s browser. No camera images, video frames or facial measurements are transmitted anywhere.
Source: https://www.npmjs.com/package/@mediapipe/face_mesh and https://www.npmjs.com/package/@mediapipe/camera_utils
Google Fonts
The widget loads the DM Sans and DM Mono fonts from fonts.googleapis.com and fonts.gstatic.com. Google receives the visitor’s IP address and browser user-agent with each font request.
When: while the widget is displayed.
Terms: https://developers.google.com/fonts/terms | Privacy: https://policies.google.com/privacy
