-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using multiple Facebook pixels in runtime #154
Comments
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. Thank you for your contributions. |
This still appears to be an issue, I'm attempting to use FacebookAds::ServerSide::EventRequest - rails active job shares class definitions between instances. |
Here's a workaround... The event request can accept an http_executor, you can construct one that matches the internals of the gem to make it seamless. The only thing I didn't support here was app secret - but you should be able to add it easily if you need it. This is thread-safe..... class RequestExecutor
def initialize(session)
@session = session
end
def execute(url, request_method, headers, params)
newParams = {
data: params[:data].to_json
}
newParams[:test_event_code] = params[:test_event_code] if params[:test_event_code]
# This part is adapted from FacebookAds::ApiRequest
faraday_response = @session.request(request_method.downcase.to_sym, url, newParams)
api_response = FacebookAds::APIResponse.new(faraday_response.status, faraday_response.headers, faraday_response.body)
if faraday_response.status.to_i >= 500
raise FacebookAds::ServerError.new(api_response)
elsif faraday_response.status.to_i >= 400
raise FacebookAds::ClientError.new(api_response)
end
json_response_object = JSON.parse(api_response.body)
return FacebookAds::ServerSide::EventResponse.new(
events_received: json_response_object["events_received"],
messages: json_response_object["messages"],
fbtrace_id: json_response_object["fbtrace_id"]
)
end
end
### Define all your event stuff here, CustomData, UserData, etc...
session = FacebookAds::Session.new(access_token: <key>)
request = FacebookAds::ServerSide::EventRequest.new(
pixel_id: pixelId,
events: [fbevent],
test_event_code: <event code>,
http_service_client: RequestExecutor.new(session)
)
response = request.execute |
Perhaps we could set the ads_pixel = FacebookAds::AdsPixel.get(fb_pixel_id)
ads_pixel.session.access_token = access_token
request = FacebookAds::ServerSide::EventRequest.new(
pixel_id: fb_pixel_id,
events: [fb_event],
test_event_code: <event code>,
)
request.execute |
We are also trying to fire events to the conversion api with multiple pixels (we store pixel_id and access_token in our DB) - we then fire postbacks for multiple pixels but it seems the first pixel to call the Is there a way to dynamically set the access_token? |
@dan003400 Check out the work around I posted above, should be thread safe... |
@sblackstone - yup seems to be working, would love if this was not needed as a work around. Thank you! |
Any progress on this issue? |
Which SDK version are you using?
v0.11.0.0
What's the issue?
Documentation not clear on how to use multiple Facebook Pixels in runtime
Observed Results:
This is the example on the Facebook page about using the API. From what I can understand is that every Facebook Pixel ID is paired with an Access Token. This is the short excerpt of how to set the facebook pixel id, but this is done globally though
Now I've dived into the code a bit and from a first short overview it looks to me that currently it's impossible to use multiple Facebook Pixel Apis, because it's impossible to set multiple Access Tokens or change them in runtime.
I also want to be kept in mind that I'm not excluding the fact that might be wrong of course. If that's the case can someone maybe point me to the right direction on how to send for instance two Server Side Event Requests with different Facebook Pixel Ids?
If this turns out to be correct, I'm of course willing to work on this issue and provide PR, unless it's in your roadmap already.
The text was updated successfully, but these errors were encountered: