Skip to main content

IP Management Guide

Understanding IP Addresses & Facebook's Preference​

The internet uses two types of IP addresses to identify devices:

  • IPv4: The traditional format (e.g., 192.168.1.1). Limited address space but still dominates global internet traffic (~60% as of 2024)
  • IPv6: The newer format (e.g., 2001:0db8:85a3::8a2e:0370:7334). Designed for unlimited scaling with better structure for matching

Facebook's Preference: Facebook increasingly recommends sending events with IPv6 addresses for better matching quality and future-proofing their systems.

The Challenge: Most visitors still use IPv4, and true conversion between IPv4 and IPv6 is technically impossible—they're fundamentally different addressing systems.

What the Module Can Do: The IP Management setting in Pixel Plus offers three approaches to handle this situation, each with trade-offs. While the setting is located in the CAPI configuration section, it affects how IPs are sent through all tracking channels: the Pixel (via custom parameters), and CAPI (server-side).

Facebook is Asking for IPv6 - Now What?​

If you're reading this guide, you've likely seen Facebook's diagnostic message recommending IPv6 format for your events. Before making changes, it's important to understand that there's no perfect solution that eliminates all warnings.

Here's why this is technically challenging:

When a visitor browses your store, their IP address is captured from multiple sources:

  1. Facebook's Pixel automatically captures it when it loads (beyond our control)
  2. The module can send it through custom parameters and CAPI (configurable)

Facebook then compares these IPs. When they differ—which happens frequently—diagnostic warnings appear.

The Reality Check: Understanding IP Sources​

The Root Issue​

Facebook Pixel's Automatic Capture: When the Pixel JavaScript loads in the visitor's browser, it automatically captures their IP address directly from the browser request. This happens before any module processing and is completely beyond our control. In most cases, this captured IP is IPv4.

The Module's IP Handling​

When you select any mode other than Raw IP, the module adds IP information to the user_data parameter in events. This parameter has both Pixel and CAPI scope—meaning the IP is sent from both channels using the same configuration.

Technical Detail

The user_data parameter is Facebook's standardized field for customer information like email, phone, and IP address. By including IP here, both browser-side (Pixel) and server-side (CAPI) events carry the same IP data.

The Core Problem​

When you select "IPv6 if available" or "Force IPv6", the module sends an IPv6 address through custom parameters and CAPI. However, Facebook's automatic Pixel capture still sees the original IPv4 address from the browser.

Result: Facebook compares:

  • Pixel automatic capture: 203.0.113.5 (IPv4)
  • Module custom parameters: ::ffff:203.0.113.5 (IPv6 format)
  • Module CAPI: ::ffff:203.0.113.5 (IPv6 format)

Facebook detects the mismatch between its automatic capture and your module data → diagnostic warning appears, even though everything is configured correctly.

Key Insight

The warnings appear not because something is broken, but because Facebook's own automatic IP capture (which you cannot control) differs from the IP format you're sending through the module.

Your Three Options Explained​

Option 1: Raw IP​

How it works: The module sends the visitor's IP exactly as captured by the server—no conversion or modification. Both custom parameters and CAPI receive the same raw IP.

What happens:

  • Visitor's actual IP (usually IPv4): 203.0.113.5
  • Facebook Pixel captures automatically: 203.0.113.5
  • Module sends in custom parameters: 203.0.113.5
  • Module sends via CAPI: 203.0.113.5

Expected warnings: Facebook may show "Consider using IPv6" because you're sending IPv4 addresses.

Pros:

  • ✅ All sources match (Pixel automatic capture, custom parameters, CAPI)
  • ✅ Most accurate representation of visitor's actual IP
  • ✅ No artificial data manipulation

Cons:

  • ⚠️ Facebook diagnostic suggests using IPv6 (informational warning)

Option 2: IPv6 If Available​

How it works: The module attempts to detect the visitor's IPv6 address by making a request to a page that only accepts IPv6 connections. If the visitor has IPv6 connectivity, it returns the IPv6 address. Otherwise, it falls back to the IPv4 address.

Smart Detection

This option performs an actual network test rather than just checking address format. If the visitor can't reach the IPv6-only page, the module knows IPv6 isn't available and uses IPv4 instead.

DNS Requirement

For IPv6 detection to work properly, your domain needs an AAAA DNS record configured. This is the IPv6 equivalent of the A record used for IPv4. Without it, IPv6 detection will always fail and fall back to IPv4. Check with your hosting provider or DNS manager to verify AAAA records are configured.

What happens (when IPv6 is available):

  • Module detects IPv6 successfully
  • Sends IPv6 to user_data in both Pixel and CAPI events
  • Facebook Pixel's automatic capture likely matches (if visitor is on IPv6)

What happens (when only IPv4 is available - most common):

  • IPv6 detection fails
  • Falls back to IPv4
  • Behaves exactly like Raw IP

Expected warnings:

  • For IPv6 visitors: Potentially fewer warnings
  • For IPv4 visitors (majority): Same "Consider using IPv6" warning as Raw IP

Pros:

  • ✅ Only sends IPv6 when it's genuinely available
  • ✅ No forced conversions
  • ✅ Graceful fallback to IPv4

Cons:

  • ⚠️ Most visitors still use IPv4, so similar warnings as Raw IP
  • ⚠️ Adds a minor detection overhead
Reality Check

Global IPv6 adoption is around 40%, and actual usage is even lower in many regions. This option will behave like Raw IP for most of your traffic.

Option 3: Force IPv6​

How it works: The module first attempts to detect IPv6 (same method as Option 2). If IPv6 detection fails, it converts the IPv4 address into IPv6-mapped format using a standardized conversion method. This ensures all IPs are sent to Facebook in IPv6 format.

Most Aggressive Option

This is the most invasive approach. It creates an IPv6 representation of IPv4 addresses, which can cause significant mismatches with Facebook's automatic Pixel capture.

What happens:

  • Module attempts IPv6 detection
  • If detection fails: converts IPv4 to IPv6-mapped format (::ffff:192.168.1.1)
  • Sends converted IPv6 to user_data in both Pixel and CAPI events
  • Facebook Pixel's automatic capture still sees original IPv4

Expected warnings: "IP address mismatch between events" because the Pixel's automatic IPv4 capture differs from the module's IPv6-formatted data.

Pros:

  • ✅ Guarantees all IPs sent in IPv6 format
  • ✅ May satisfy Facebook's IPv6 diagnostic preference

Cons:

  • ❌ Creates intentional mismatch with Pixel's automatic capture
  • ❌ Often generates more diagnostic warnings
  • ❌ IPv6-mapped addresses aren't true IPv6 connections
  • ❌ Can confuse Facebook's matching algorithms
Historical Note

Facebook once suggested this approach informally, but it often creates more problems than it solves by introducing mismatches where none would otherwise exist.

Our Recommendation: Raw IP (or IPv6 If Available at most)​

After extensive implementation experience, we recommend Raw IP for most stores. If you want to take a more proactive approach, IPv6 If Available is acceptable, but avoid Force IPv6 unless absolutely necessary.

Recommended Approach

Raw IP for simplicity and accuracy, or IPv6 If Available if you want to prioritize IPv6 when genuinely present. Both are reasonable choices.

Why avoid Force IPv6?

Force IPv6 is an extreme measure that creates intentional mismatches. It converts IPv4 into an IPv6 representation, which:

  • Doesn't reflect the visitor's actual network connection
  • Creates discrepancies with Facebook's automatic Pixel capture
  • Often generates more (and different) warnings than it prevents
  • Can confuse Facebook's matching algorithms

Why Raw IP works well:

  1. Consistency: All IP sources match—Facebook's automatic capture and your module data show the same IP
  2. Accuracy: Represents the visitor's actual network address
  3. Predictability: One warning type ("Consider using IPv6") rather than conflicting warnings
  4. Simplicity: No conversions or detection overhead

Why IPv6 If Available is acceptable:

  1. Smart detection: Only uses IPv6 when it's genuinely available
  2. Graceful fallback: Behaves like Raw IP when IPv6 isn't present
  3. Future-proof: Prioritizes IPv6 as adoption increases
  4. No forced conversions: Doesn't create artificial mismatches
About Diagnostics

You'll see warnings with any option:

  • Raw IP: "Consider using IPv6"
  • IPv6 If Available: Same warning for most IPv4 visitors
  • Force IPv6: "IP mismatch" warnings

The goal isn't zero warnings—it's accurate tracking.

What about the Facebook warning?

Yes, you'll see "Consider using IPv6" in diagnostics. But here's the important part to understand:

Facebook Diagnostics Are Recommendations

Facebook's diagnostic warnings are suggestions and recommendations, not mandatory requirements. They highlight potential optimizations but don't indicate broken tracking. Many successful stores run with these warnings permanently.

Configuration Steps​

  1. Navigate to Pixel Plus Configuration → CAPI Options → IP Management
  2. Select "Send IP as captured (Raw)" or "IPv6 If Available"
  3. Click Save
  4. Clear PrestaShop cache: Advanced Parameters → Performance → Clear cache
  5. Monitor results for 7 days before making any changes
Avoid Frequent Changes

Switching IP configurations frequently creates inconsistent data. Choose one option and let it run for at least a week before evaluating results.

Final Recommendations​

For Most Stores​

Start with Raw IP. It's simple, accurate, and creates no artificial mismatches.

For Proactive Stores​

"IPv6 If Available" is a reasonable choice if you want to prioritize IPv6 when it's genuinely present without forcing conversions.

What to Avoid​

"Force IPv6" is an extreme measure that creates more problems than it solves. Only use it if Facebook support specifically recommends it for your situation.

Bottom Line

There is no configuration that eliminates all Facebook diagnostic warnings. IPv4 still dominates internet traffic, and Facebook's automatic Pixel capture will always see the visitor's real IP. Choose the option that provides accurate data—Raw IP or IPv6 If Available—and focus on metrics that actually matter: Event Matching Quality and conversion tracking.