The default Twitter pixel script contains this code
twq('track','PageView');
to trigger a PageView event (conversion).
In the documentation it states:
Choose the type of conversion you’d like to track with this tag. Your Twitter Ads dashboard reports on conversions by conversion type.
Here are the types:
Site visit: User visits your site
Purchase: User completes a purchase of a product or service on your
site
Download: User downloads a file, such as a white paper or software
package, from your site
Sign up: User signs up for your service, newsletter, or email
communication
Custom: This is a catch-all category for a custom action that does not
fall into one of the categories above
Does this mean that I can trigger these conversion types by the twq('track', event) function? If so, what is the syntax?
It appears they've expanded their documentation slightly in this regard, but it's still vague:
A conversion event can be any "Action" that a user completes on your site which you would like to track. It does not have to be a purchase, but can also be a shopping cart update, a newsletter sign up, etc. Choose the type of conversion you’d like to track with this tag. Available tag types are Site Visit, Purchase, Sign Up, Download, or Custom. Choose “Custom” if you’re tracking an action other than the conversion events we’ve predefined.
There is, however, an example of this in the documentation:
Under the question How to setup advanced conversion tracking to monitor campaign ROI? there's this:
You'll notice the Purchase event, above. Unfortunately it doesn't give up the syntax for the two word events like Sign up. Sigh.
There is also this post on their developer forums from an employee (date Jan 2018) indicating they are moving away from the other custom event types:
Due to a roadmap change, we are actively supporting “PageView” and “Purchase” tag types. But this does not mean that you can’t still track sign ups or custom events.
In their documentation there is also this disclaimer:
The purchase tag must executed independently of 'PageView' tag type, otherwise the dynamic values will be overwritten.
This appears to suggest these additional event types must be in replacement of the PageView event, but again it's unclear. If you tell Twitter to create a Purchase conversion event, the snippet it provides still uses PageView. It's very confusing.
Update: From my tests it appears the above code (with Purchase event) fires, and is tracked correctly, by Twitter.
Related
I have a question about the update of the status of an order.
I create the basket using OCAPI and then I can successfully create an order with
https://mydomain/dw/shop/v21_10/orders (POST)
Order is fine. All data are there.
Now the order has status CREATED and I want to change it to OPEN using the Shop API again.
https://mydomain/dw/shop/v21_10/orders/MyOrderNumber (PATCH)
This is the message I receive
{"_v":"21.10","fault":{"arguments":{"statusFrom":"CREATED","statusTo":"OPEN"},"type":"StatusTransitionNotPossibleException","message":"The status transition from 'CREATED' to 'OPEN' isn't possible."}}
While if I try to make the same transition in Business Manager it works perfectly.
Anyone knows why?
The reason you can't transition the order from CREATED to OPEN is because there is a step in between.
Unfortunately, this is poorly documented in OCAPI docs, but we can see a clearer picture if we look at the DW API docs which explain in more detail.
A bit of background
First, notice the description of the PATCH /orders/{order_no} endpoint:
same status transitions are possible as for dw.order.Order.setStatus(int status) plus CREATED to FAILED)
Okay, so it follows the DW API rules. Let's take a look at the Order.setStatus() method (emphasis mine):
This method does not support order statuses ORDER_STATUS_CREATED or ORDER_STATUS_FAILED. Please use OrderMgr.placeOrder(Order) or OrderMgr.failOrder(Order).
So this is telling us that we can't move an order out of CREATED status except by either placing it or failing it. If we take a look at the documentation for OrderMgr.placeOrder(order), it corroborates this:
This method places an order and is usually called after payment has been authorized. The specified order must be in status CREATED, and will be set to status NEW.
Now back to OCAPI
Now we know that OCAPI generally follows the same rules as the DW API when it comes to transitioning order statuses. (with the exception of CREATED -> FAILED)
So how do we go about placing an order with OCAPI?
With OCAPI, you can place an order by calling POST orders/{order_no}/payment_instruments which will trigger the following hooks:
Authorize the payment with either dw.order.hooks.PaymentHooks.authorizeCreditCard or dw.order.hooks.PaymentHooks.authorize, depending on the payment type
Place the order with dw.ocapi.shop.order.afterPostPaymentInstrument
On success of both those hooks, your order will now be in NEW status, and ready to be transitioned into OPEN.
This discussion is on the same topic, although talking about the controller context, not OCAPI.
So, even though business manager lets you get away with stuff (I assume so that admins can override things where necessary), in the context of OCAPI or a controller, the order has to follow the regular placement steps.
I want to integrate recurring payment using Payeezy in codeigniter. I have implement the single time payment using curl and now i want to recurring payment with acknowledgement to update my DB.
I created a WordPress plugin for Payeezy that also handles recurring. You should be able to use the underlying PHP code for CodeIgniter.
https://wordpress.org/plugins/wp-payeezy-pay/
I can explain the process that will get you the least PCI compliance issues, and that's the token-based API.
1. Generate Token in Payment Form
So basically you'll use the Javascript API to generate your authorize token. An authorize token doesn't charge the card. It's for validating the card and returning a token for better PCI compliance. This API source code and explanation is here:
https://github.com/payeezy/payeezy_js
2. Post Form To Your Server for the Curl Call to FirstData
Then, once you have this token, you post it back to your controller file with a standard form post, but remove the name attribute on your credit card number and credit card CVC fields so that these do not post to your server. Note that you'll need to store this data (but not card number and CVC) because on refunds (and subscription cancellations) you'll need to reply back with the last purchase token, cardholder name, card type, card expiration date, amount spent, and currency code. You may wonder why FirstData/PayEezy is asking you to store cardholder name, card type, and card expiration date. Well, there's a perfectly good explanation for that. Your call center may need that detail for troubleshooting an issue over the phone with a customer. Also, you need that for refunds. And, most importantly, if you're doing a recurring subscription payment, your code needs to look at the expiration date ahead of time before charging because the API call will fail if the card is past expiration. Last, because you're not storing the credit card number and credit card validation (CVC) code, you're going to be in stronger PCI compliance.
From there, since you are already familiar with the Curl process for a single-purchase, it's just a minor single field change (transaction_type becomes 'recurring') in the Curl to do the recurring. For anyone not familiar with the Curl process, it's explained here:
https://developer.payeezy.com/payeezy-api/apis/post/transactions-4
Also, for those unfamiliar people, you'll need to read up on how FirstData/PayEezy wants you to send in the Curl request with a special header that includes Content-Type: application/json, apikey, token, Authorization, nonce, and timestamp. You can see more detail about that here:
https://github.com/payeezy/payeezy_direct_API/blob/master/payeezy_php/example/src/Payeezy.php
(What I did to make that code simpler was intercept the Curl calls from that script into a log file so that I could make it much more straightforward in a single function instead of breaking it up into all these little functions. That made it far easier to understand what was going on.)
3. Switching Curl Call for Recurring Payments
So, as you discovered in your Curl call, you saw how to do a one-time purchase by setting the transaction_type to 'purchase'. For doing recurring, you set transaction_type to 'recurring'. You have to do that from the start. So, if I'm selling something for $29.99 monthly, the very first month charge needs to still be set to type 'recurring', as would any subsequent month.
4. Your Responsibilities for Recurring Payments
Now, this is where everyone gets hung up because it's poorly documented unless you check the PayEezy Developer Support Forum. For subscriptions, PayEezy doesn't have a system for setting payment plans with varying durations, nor setting up automatic (set-it-and-forget-it) subscriptions for you. (I think I read that they have something experimental on Apple Pay, but nothing else yet.) So, to achieve this, you have 2 choices:
Use Chargify.com. Unfortunately, though, this increases CPA (Cost Per Acquisition) of your product or service. You'll have to factor that in if you want to use that. This basically is a SaaS service that you send the transaction to and they handle the automatic subscription plan for you against FirstData/PayEezy.
Roll your own cron job solution. To do this, you basically take the Curl code for a single transaction, and change the transaction type from 'purchase' to 'recurring'. (Do that from the start -- don't start with 'purchase' on a recurring charge.) From there, it's up to you with your own cron job to check for product or service expiration terms, and then send the API call back off to FirstData/PayEezy for charging that card again with the 'recurring' transaction_type.
On either of those options, the customer never gets asked to enter in credit card data past the first time unless their card expires or unless you have some problem billing that card (like insufficient funds).
Of course, doing your own cron job route for the recurring payment has implications you'll need to prepare for:
Add some failsafe code so that you prevent the possibility of duplicate transactions, such as a database field.
Add some failsafe code such that if you have cancelled a subscription, you won't charge them again.
Add some failsafe code such that if they cancel their subscription, yet purchase it again as a subscription at a later time, that you do charge them again and don't block it from your other failsafe code.
Add some sort of grace period on your product or service such that even if you "say" that the term expired, you have like a 2 day grace period so that your API has a chance to do a renewal.
It's probably a good idea to email the customer before their renewal period so that they can make certain they have money in their account and have a way to cancel that charge (like call your office or call center, or have a link to click where you provide a way to cancel).
If their card has expired before the renewal, and you detect that in the warning email that comes before renewal, then you'll want to let them know this.
If their card has been declined for any reason at the point of renewal, then you'll want to let them know this and give them a link to go through the cart again to buy it again, or some other way to save that transaction in your code.
How To Do Subscription Cancellations / Stop Recurring Payments
To stop a recurring payment, you treat it just like a refund on a single purchase, but use the transaction ID of the last purchase. This is documented with this Curl example here:
https://developer.payeezy.com/payeezy-api/apis/post/transactions/%7Bid%7D-0
Look under "Refund" and choose Token.
How does one go about using the MailChimp API to create a two-step signup process? I'm having a really hard time finding any documentation for this. It should go like this:
Step 1:
The website shows a sign up form with just an email field and a subscribe button. Once someone fills out her/his email address and hits 'Subscribe', the email address gets added to the list, and then additional options show up in a modal window (name, location, interests, etc.)
Step 2:
At this stage the user has already been added to the mailing list. The user can now choose to fill in the additional fields in the modal window (which will then be added to her/his account), or if he doesn't, then certain default values are added, after which a thank you message is shown.
Any help would be greatly appreciated! Thank you.
I would suggest that you use a single signup form as you capture your subscribers ... users rarely want to do something in two steps. Make it easy for them to take all the actions they want in one screen.
When you design your form, consider what information is mandatory and what is optional. You will need to think of how you will use the fields, groups, etc later in campaigns.
You can provide default values for many of the fields. You can also specify what message to send for an initial subscription.
Remember, a user is not "subscribed" until they accept the "did you really mean to subscribe" email that is automatically send by MailChimp.
I am having a register form that user fill in, once the form fill in, the registration is postponed till the user recieve an email to check that his email is ok, then when he reply the email, the registration is fully proceed.
I would like also the process to be automatic, without the need for the user to entered any number ect, just the need for him to click on the email to confirm, and automatic on my side too.
I want the process to be available to some others task than the registration process as well if possible.
Do I need to do all way check/123456 with the 123456 generated or is there a better way to do, a component, nuget that can do the job ? you experiences return would be helpful
thanks
You appear to be on the right track.
I do a similar thing quite often. It isn't generic since I do not need it but you can change that quite easily.
Once a user registers I send an activation e-mail that contains a link that when clicked navigates to something such as http://domain/member/activate/id where the id is a GUID. That is all I need. I look up the member id and activate it. Chances of someone guessing a new member's id are rather slim and even if they do it is very far from a train smash.
From what I can tell you need something more generic and a bit more security. You could always create some key (like a new GUID) that you store along with the user and then the activation calls: http://domain/member/activate/id?key={the guid}. You could even encrypt the key. But that is up to you.
For something that can be re-used and is more generic you could create an activation component that contains a list of activation ids. But to then activate a specific type of entity (such as user registration or form validation) you would need to have a way to perform that on the back-end. For example, when you call http://domain/activation/activate/id internally is looks up the id and gets the type. The activation request is, of course, created when, e.g., your user registers. You would probably want to store some expiry/timeout since a user may never activate.
For each type you could have an activation mechanism on the relevant controller: member/activate/key or formvalidation/activate/key. So when you activation controller receives a request to activate it has a list of routes conigured per type and the navigates to the relevant route to perform the 'actual' activation.
Another option is to have an in-process component perform activation e.g.: an IActivator interface implemented by a MemberActivator or FormValdationActivator and then have an IActivatorProvider implementation that gives you the relevant provider based on a type (.NET Type or a string type you provider --- that's up to you).
You could even pass an ActivationRequestCommand along to a service bus endpoint if you are so inclined.
So you have many options. HTH
If you are a developer I suggest you at least try to start with the code... then ask again if you get stuck providing a sample of what you've done.
What you are looking to do is basically use a temporary url that posts to a page to complete the registration...
I'm writing an application that queries a user's Outlook calendar to see if they are available to be contacted "right now" (i.e., they do not have a current appointment that is marked as Away or Out Of Office).
I'm using the GetUserAvailabilityRequest xml message and it's working well, but I'm a bit confused as to what I should use for the AttendeeType.
AttendeeType is a field that allows me to specify the kind of meeting attendee I'm looking for -- whether it's the meeting organizer, a required attendee, an optional attendee, a room resource, etc.
But for this application I don't care about the attendee type; I only care if the person has a current appointment that marks them as unavailable. If Bob is out of his office attending a meeting, I don't care if he put the meeting together or if he was invited by Carol; I only care that Bob is out of his office.
Is there a value I can use for AttendeeType that will catch all attendee types? Most of the examples I've seen use the value "Required", but they don't explain why.
I've found that both OptionalAttendee and RequiredAttendee are valid, so the choice to use RequiredAttendee is entirely stylistic/arbitrary.
I believe that this is sort of a hypothetical query, like "If this person were to come to an event at this time as an optional attendee (or as a required attendee), would they have conflicts?" So it doesn't matter if they are required or optional.
As an aside, resources are things like projectors and rooms, so I'm not sure what would happen if you tried to check a person as a resource, but I imagine it wouldn't work out.